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1 

SUMMARY 


The  mereos1  program  is  an  Enabling  Technology  Developments  and  Demonstrations  (etdd)  project 
of  the  Agile  Manufacturing  Pilot  Program  (ampp)  funded  by  the  United  States  Air  Force  Research  Lab¬ 
oratory,  Materials  &  Manufacturing  Directorate,  Manufacturing  Technology  Division  (afrl/mlm) 
under  contract  F33615-95-C-5519. 

Mereos  is  one  element  of  the  Platform  for  Automated  Construction  of  Intelligent  Systems  (pacis®) 
project.  The  two  primary  mereos  program  objectives  were  first,  to  identify  the  root  causes  of  the 
multiple  bom  reconciliation  problem  and  define  the  requirements  for  a  solution,  and  second,  to 
prove,  via  demonstration,  the  feasibility  of  developing  a  system  to  implement  that  solution. 

The  technical  aim  of  the  pacis  project  is  to  produce  a  next-generation  database  programming  sys¬ 
tem  that  provides  the  tools  required  to  develop,  deploy  and  sustain  large-scale  manufacturing  enter¬ 
prise  decision  automation  systems.  The  strategic  aim  of  the  project  is  to  enhance  the  value  of 
solutions  enterprises  deliver  to  their  stakeholders  by  bringing  automation  to  bear  on  enterprise 
integration  and  on  critical  processes  in  their  value  streams— specifically,  those  processes  requiring 
extensive  experience  and  cognitive  skills  to  execute  or  govern— and,  accordingly,  those  which  have 
heretofore  been  intractable  to  any  but  the  most  superficial  automation.  Launched  in  1981  as  a  pri¬ 
vately  funded  effort  led  by  the  team  who  founded  Ontek  Corporation  in  1985, 2  the  pacis  project  has 
been  funded  since  then  by  afrl/mlm  and  several  industrial  organizations.3 


1  An  ungrammatical  plural  rendering  of  the  Greek  term  pepiG  (part) -thus,  “parts.” 

2  The  project  originated  as  an  effort  to  develop  a  decision  automation  system  for  Reynolds  &  Taylor,  Inc.,  a  second  tier 
aerospace  &  defense  subcontractor  located  in  Santa  Ana,  California. 

3  Alcoa,  Northrop  Aircraft  Division,  Westinghouse  Electronic  Systems  Group,  and  Lockheed  Martin  Aeronautical  Sys¬ 
tems.  Beginning  in  late  1999,  the  Lockheed  aeronautics  sector  companies  were  consolidated  into  a  single  company 
called  LM  Aero,  which  is  headquartered  in  Ft.  Worth,  Texas. 
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Information  is  the  raw  material  of  decision-making,  and  information  systems  are  instrumentali¬ 
ties  for  provisioning  decision-making  processes— they  are  tools  for  provisioning  purposeful 
thought.  The  value  of  any  particular  tool  to  a  potential  user  ultimately  consists  in  two  attributes. 
The  first  is  its  applicability  to  the  aims  of  a  user— its  utility .  The  second  is  its  capability  to  facilitate 
accomplishment  of  those  aims— its  effectiveness.  In  the  final  analysis,  the  value  of  a  tool  can  only  be 
gauged  by  using  it. 

Pacis  is  a  tool  for  creating  decision  automation  systems— specific  types  of  information  systems— it 
is  a  tool  for  toolmakers.  Its  value  accordingly  consists  in  its  instrumental  applicability  to  the  aims  of 
those  users  and  in  its  effectiveness  in  enabling  accomplishment  of  their  aims.  This  makes  it  difficult  if 
not  impossible  to  demonstrate  its  value  to  executive  management  and  other  indirect  beneficiaries 
of  the  technology.  To  overcome  this  inherent  Value  visibility’  problem,  we  have  over  the  years  pro¬ 
duced  and  demonstrated  solutions  to  visible  albeit  technical  needs  of  those  who  would  ultimately 
benefit  from  decision  automation  systems:  executive  management  and  support  staff.  Mereos  is  the 
most  recent  of  these. 

Mereos  program  execution  was  structured  into  three  distinct  phases  in  accordance  with 
etdd/ampp  project  requirements.  These  were: 

Phase  I  Technology  Feasibility  Dec  94-Dec  95 

Phase  II  Prototype  Demonstration  Jan  96-Dec  98 

Phase  III  Pilot  Production  Implementation  Jan  99-Jan  00 

The  original  mereos  Statement  of  Work  (sow)  addressed  Phase  I  and  II  tasking.  Phase  III  was  an 
option  which  required  separate  authorization  and  a  second  specific  sow.  All  three  phases  were  exe¬ 
cuted. 

The  mereos  program  was  originally  conceived  as  an  information  systems-centric  effort  to  identify 
the  requirements  for  and  demonstrate  a  solution  to  the  multiple  bom  reconciliation  problem.  While 
these  original  program  objectives  were  achieved,  the  program  underwent  a  transformation  in  both 
focus  and  venue  during  its  execution.  We  set  out  to  solve  an  informatics  problem:  we  accomplished 
that,  but  also  ended  up  solving  several  enterprise  architecture  problems  as  well,  resulting  in  a  base¬ 
line  for  a  new  aerospace  enterprise  operating  system.  The  reasons  for  this  ostensibly  radical  shift 
are  discussed  at  some  length  in  paragraph  2.6  in  the  Introduction. 

Principal  program  results  consist  in  formal  requirements  definitions  for  two  specific  systems.  One 
was  for  a  new  kind  of  product  data  management  system.  The  other  was  for  a  new  kind  of  enterprise 
operating  system.  The  first  was  demonstrated  by  software.  The  second  was  demonstrated  by  execu¬ 
tion  of  an  enterprise  architecture  program.  Each  are  directly  related  to  the  other,  albeit  in  complex 
and  intricate  ways.  The  former  results  are  complete,  and  are  presented  in  Section  3:  Results  Part  I. 
The  latter  is  a  work  in  progress,  although  by  the  end  of  the  program  a  great  deal  of  work  had  been 
accomplished,  and  a  great  many  lessons  had  been  learned.  The  results  obtained  as  of  December  2000 
are  presented  in  Section  4:  Results  Part  II. 
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Intelligence  is  the  faculty  of  making  artificial  objects,  especially  tools  to  make  tools.’ 

Henri  Bergson,  [.’Evolution  Creatrice 
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INTRODUCTION 


The  mereos  program  is  one  element  in  a  larger  multi-year  effort  called  the  pacis  project.  It  was 
designed  to  serve  three  purposes  in  that  context.  The  first  was  to  demonstrate,  via  a  specifically  tar¬ 
geted  application,  the  technical  capabilities  and  strategic  business  value  of  pacis  technology  to 
potential  user  organizations.  The  second  was  to  provide  a  technical  focus  for  a  major  re-design  of 
pacis  representation  system  metastructures.  The  third  was  to  provide  a  suitably  complex  test  bed  for 
internal  evaluations  of  pacis  representation  system  capabilities  and  performance. 

2.1  Pacis  Program  Objectives 

The  goal  of  the  pacis  project  is  to  produce  a  next-generation  database  programming  environment 
that  provides  the  tools  required  to  develop,  implement  and  sustain  enterprise  management  decision 
automation  systems.  A  decision  automation  system  is  a  large,  geographically  distributed  intelligent 
computing  system  designed  to  automate  many  of  the  management  support  staff  functions  currently 
performed  by  human  beings.  One  can  think  of  decision  automation  systems  as  white  collar  robots 
and  pacis  as  a  tool  for  building  and  maintaining  them. 

The  specific  objective  of  a  management  decision  automation  system  is  to  enhance  the  economic 
viability  and  agility  of  an  enterprise  by  automating  tasks  that  require  extensive  expertise,  such  as 
change  impact  analysis,  resource  allocation,  tactical  plan  development,  make/buy  decisions,  and  so 
on.  Existing  enterprise  systems  do  not  automate  these  kinds  of  activities.  At  best  they  provide  some 
of  the  more  mundane  information  management  and  computation  services  that  people  need  to  per¬ 
form  them.  The  high  non- touch  labor  cost  content  of  total  product  cost  (60  -  70%)  in  most  manu¬ 
facturing  industry  sectors  is  one  symptom  of  this  phenomenon;  the  tremendous  costs  and  long  lead 
times  associated  with  incorporating  engineering  changes  into  complex  products  is  another. 

The  central  tenet  underlying  our  approach  to  pacis  is  that  decision  automation  systems  cannot  be 
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built,  let  alone  implemented  and  sustained,  without  extensive  automation.  That  is,  the  tasks  of  con¬ 
structing,  implementing,  and  sustaining  decision  automation  systems  must  themselves  be  auto¬ 
mated.  The  two  most  daunting  characteristics  of  management  decision  automation  systems  are  their 
physical  and  conceptual  scales.  The  existing  automated  information  assets  of  a  reasonable  size 
enterprise  are  measured  in  the  multiple-terabytes,  as  the  figure  below  illustrates.4 


# 

Description  Of  Metric 

Value 

1. 

Total  Number  Of  Distinct  Programs 

307,350 

2. 

Total  Number  Of  Lines  Of  Source  Code 

288,391,200 

3- 

Total  Number  Of  Information  Entity  Databases 

14,130 

Total  Number  Of  Information  Entities 

20,790 

7~1 

Total  Number  Of  Information  Entity  Data  Elements 

401,670 

Figure  1.  Informatic  Scale  of  a  Large  Multinational  Enterprise 

Any  management  decision  automation  system  would  have  to  manage  a  substantially  larger  infor¬ 
mation  base.  Thus,  the  physical  scale  is  well  beyond  the  current  approach  to  database  manage¬ 
ment. The  conceptual  scale,  required  to  support  management  decision  automation,  is  likewise 
beyond  the  current  capabilities  for  representing  the  knowledge  of  an  enterprise.  A  system  providing 
a  fusion  of  these  capabilities  at  the  required  physical  and  conceptual  scales  does  not,  as  yet,  exist. 

2.2  Pacis  System  Architecture 

Pacis  is  made  up  of  four  component  subsystems.  These  are: 

1.  Nucleus 

The  pacis  nucleus  is  a  portable  distributed  virtual  machine  providing  a  comprehensive  suite 
of  computing  services  to  the  other  pacis  subsystems.  These  services  include  host  computing 
platform-independent  program  invocation  and  runtime  management,  memory  manage¬ 
ment,  i/o,  and  network  communications. 

2.  Information  management  subsystem 

The  pacis  information  management  subsystem  is  an  ansi[1]  and  iso[9]  3-schema  compliant 
dbms  providing  a  unified  information  definition,  delivery,  and  management  environment 
supporting  transparent  and  dynamic  access  to  information  contained  in  heterogeneous 
databases  residing  on  distributed  heterogeneous  computing  platforms.  The  core  of  this  sub¬ 
system  is  a  knowledge  representation  system  that  supports,  among  other  things,  represen¬ 
tations  of  processes,  and  intensional  contexts  as  first-class  entities;  direct  representation 
and  manipulation  of  foreign  system  schemata  and  operations;  and  a  comprehensive  classifi¬ 
cation  system  that  supports  the  definition  and  manipulation  of  distinct  kinds  of  taxonomic 
schemes  in  several  alternative  topologies. 

3.  Presentation  subsystem 

The  pacis  presentation  subsystem  contains  two  distinct  components:  the  human  interface 
system  and  the  application  program  interface.  The  human  interface  system  provides  an 


4  These  numbers  represent  estimates  we  developed  during  our  participation  in  the  Alcoa  Information  Architecture  pro¬ 
gram  from  1989-1991.  They  are  of  course  outdated  now;  the  current  physical  scale  of  Alcoa  applications  and  data¬ 
bases  would  of  course  be  much  larger  than  this. 
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extensive  suite  of  interactive  graphical  interfaces  and  hardcopy  reporting  facilities  required 
for  user  interaction  with  pacis.  The  application  programming  interface  is  a  library  of  call¬ 
able  functions  and  routines  that  enable  third-party  system  developers  to  access  the  pacis 
nucleus  and  information  management  subsystem  services  from  their  applications. 

4.  Semantic  repository 

The  pacis  semantic  repository  is  a  collection  of  knowledge  bases  containing  definitions  for 
a  broad  class  of  entities  commonly  encountered  in  business  environments. 

The  current  version  of  pacis  is  based  upon  over  15  years  of  research  and  development  whose  goal 
is  the  fusion  of  knowledge  representation,  database  management  systems,  and  declarative  program¬ 
ming  technologies. 

2.3  Pacis  Project  History 

The  pacis  project  began  in  1981  as  an  effort  to  develop  a  decision  automation  system  for  Reynolds  & 
Taylor,  a  second-tier  aerospace  job  shop  employing  250  people,  located  in  Santa  Anna,  California. 
By  1985,  a  version  of  that  system  had  been  developed  and  successfully  implemented  in  the  com¬ 
pany.  The  Reynolds  &  Taylor  system  was  a  fully  integrated  job  shop  management  system  that  pro¬ 
vided  extensive  automation  for  tasks  such  as  estimating,  process  planning,  material  management, 
mil-q-9858  compliant  quality  management,  and  far/dfars  compliant  finance  and  administration. 
This  system  was  in  turn  built  using  a  precursor  of  pacis  developed  between  1981  and  1984.  The  sys¬ 
tem  was  used  to  operate  Reynolds  Sc  Taylor  until  the  company  was  sold  in  1989. 

Because  the  Reynolds  Sc  Taylor  system  provided  functionality  unavailable  in  other  much  larger 
systems,5  the  project  attracted  the  attention  of  both  the  Air  Force  and  several  prime  contractors— 
notably  Northrop  Aircraft  Division,  Alcoa,  and  Westinghouse  Electronic  Systems  Group— who  were 
customers  of  Reynolds  Sc  Taylor.  As  a  result,  in  late  1985  the  Air  Force  Materials  Laboratory,  Manu¬ 
facturing  Technology  division  (now  afrl/mlms)  awarded  Reynolds  Sc  Taylor  a  Small  Business  Innova¬ 
tion  Research  (sbir)  contract  to  improve  the  capabilities  of  the  original  tools  used  to  build  the 
system  and  scale  them  to  the  point  where  they  could  be  used  to  develop  similar  systems  for  prime 
contractors.  In  response  to  this  award,  matching  funds  were  provided  by  Alcoa,  Northrop,  and 
Westinghouse,  the  original  project  team  formed  Ontek  Corporation,  and  the  sbir  contract  was 
novated  from  Reynolds  Sc  Taylor  to  the  new  company. 

From  1986  to  1988,  the  team  conducted  fundamental  research  in  knowledge  representation, 
focusing  on  developing  techniques  for  encoding  and  manipulating  the  complex  cognitive  processes 
and  semantic  structures  involved  in  manufacturing  enterprise  management.  This  work  culminated  in 
the  development  of  a  prototype  representation  system  which  was  demonstrated  to  a  large  industry 
and  DoD  group  in  early  1988.  Based  upon  that  demonstration,  Northrop  awarded  Ontek  a  major 
subcontract  under  the  Automated  Airframe  Assembly  Program  (aaap)  to  develop  a  full-scale  version 
of  the  system— by  then  designated  pacis.  The  first  working  version  of  pacis  was  delivered  to 
Northrop  in  December  of  1989. 

The  first  version  of  pacis  was  used  to  develop  several  experimental  application  systems,  each 
designed  to  test  and  demonstrate  a  key  capability  required  for  its  eventual  use  as  a  platform  for 
management  automation  systems.  Three  of  these  were: 

I  Concurrent  engineering  model  integration  system;  an  application  for  modelling  and  analy¬ 
sis  of  the  To-Be  configuration  of  the  Northrop  Product  Definition  and  Development  Center 
(pddc),  the  Integrated  Product  Definition  (ipd)  organization  for  the  f-23  program.  This  sys¬ 
tem  was  developed  to  demonstrate  the  ability  of  pacis  to  represent  complex  processes  and 
conceptual  structures,  and  was  used  to  model  program  organization  structure,  activity  flow, 
documentation  trees,  and  product  structures  in  a  single  unified  environment,  and  sup¬ 
ported  interactive  graphical  analysis  and  simulation  of  these  structures. 

5  Raw  material  lot  and  batch  number  traceability  by  part  serial  number;  actual  cost  by  part  serial  number;  shop  sched¬ 
uling  to  the  machine  tool/operator  level;  non- destructively  updated  databases;  fully  dynamic  user- definable  ad-hoc 
queries;  etc. 
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I  Legacy  database  integration  system;  an  application  supporting  dynamic  ad-hoc  queries 
across  distributed  heterogeneous  databases,  including  ims,  db2,  and  oracle.  One  of  the 
major  subsystems  in  this  application  was  an  ims  schema  acquisition  system,  which  was 
developed  to  demonstrate  the  ability  of  pacis  to  subsume  other  database  management  sys¬ 
tem  schemata.  This  subsystem  automatically  generated  pacis  representations  of  ims  database 
systems  directly  from  compiled  binary  on  ibm  mainframes.  The  legacy  database  access  sys¬ 
tem  was  used  to  support  several  other  demonstration  applications  at  Northrop  under  the 
aaap,  at  Alcoa,  and  at  Westinghouse. 

I  Material  status  reporting  system;  an  application  developed  for  the  Westinghouse  Advanced 
Development  Organization  (ado)  to  provide  material  status  accounting  on  outside  pur¬ 
chases  and  inventory  for  prototype  product  development.  This  system  was  developed  to 
demonstrate  the  ability  of  pacis  to  provide  commercial  third-party  applications  with  trans¬ 
parent  access  to  legacy  databases.  It  enabled  end  users  to  directly  access  information  con¬ 
tained  in  both  ims  and  db2  databases  via  excel  spreadsheets  on  a  Macintosh.  Prior  to  the 
implementation  of  the  application,  this  process  took  one  person  up  to  5  days  of  elapsed 
time  to  perform.  The  application  produced  more  accurate  information  than  the  manual 
procedure  and  required  an  average  of  15  minutes  of  elapsed  time  to  execute. 

Work  began  in  late  1991  to  transition  the  project  from  a  focus  on  r&d  to  full-scale  development 
of  a  production  version  of  the  system.  These  activities  were  funded  by  afrl/mlms  under  the  Corpo¬ 
rate  Data  Integration  Tools  (cdit)  program,  with  additional  funding  from  Alcoa  and  Westinghouse, 
and  continuing  technical  support  from  Northrop.  The  objectives  of  these  transitional  activities  were 
to  develop  a  formal  methodology  for  semantic  analysis,  to  support  the  creation  of  pacis  knowledge 
bases  for  use  in  an  enterprise  integration  environment,  and  to  develop  new  pacis  interfaces  to  sup¬ 
port  the  methodology.  By  the  end  of  1993,  the  new  analysis  methodology  had  been  developed,  a 
new  suite  of  interface  tools  to  support  pacis  knowledge  base  definition  had  been  produced,  and 
preliminary  high-level  designs  for  a  new  production  version  of  the  system  had  been  developed. 
Detailed  design  and  preliminary  development  of  the  new  production  version  of  pacis  began  in  Janu¬ 
ary  of  1994,  funded  by  wl/mt  under  the  Advanced  Enterprise  Integration  (aeip)  program. 

The  overall  goals  of  the  aeip  program  were  to  improve  pacis  system  performance  and  maintain¬ 
ability,  and  to  develop  the  software  infrastructure  required  to  implement  a  database  programming 
language  (dbpl).  Three  specific  objectives  were  established  to  support  these  goals:  redesign  of  the 
pacis  nucleus;  design  for  the  pacis  dbpl;  and,  selection  of  a  suitable  demonstration  application  for 
the  new  version  of  pacis. 

2.4  The  Strategic  Problem:  Demonstrating  Pacis 

Tools,  whether  concrete  or  abstract,  are  instrumentalities  for  performing  actions.  Tools  are  a  means 
to  achieve  certain  ends,  and  are  not,  in  that  context,  ends  in  and  of  themselves.  The  efficacy  of  a 
tool  is  a  measure  of  two  fundamental  characteristics:  the  range  of  actions  the  tool  enables  its  users 
to  execute— its  amplitude— and  the  efficiencies  one  obtains  by  using  that  tool— its  effectiveness.  But 
because  a  tool  is  a  means  to  an  end,  the  overall  value  of  a  tool  is  inherently  indirect;  that  is,  its  value 
is  dependent  upon  the  value  of  the  products  that  are  produced  by  using  it. 

Information  systems  are  tools  that  are  used  by  people  to  operate  an  enterprise.  Like  any  other 
tool,  the  value  of  an  information  system  can  only  be  determined  indirectly;  that  is,  by  measuring 
the  degree  to  which  using  that  system  improves  the  ability  of  people  to  achieve  the  goals  of  the 
enterprise  they  operate.  However,  information  systems  are  inherently  very  complex;  they  are  more 
like  5 -axis  spar  mills  than  hammers.  Because  of  this,  information  systems  require  a  multitude  of 
subsidiary  tools  in  order  for  them  to  be  economically  built  and  maintained.  Among  these  are  such 
subsystems  as  operating  systems,  compilers,  and,  of  course,  database  management  systems. 

Database  management  systems  are  instrumentalities  for  performing  storage  and  retrieval  opera¬ 
tions  on  the  data  that  the  information  systems  they  host  acquire,  manipulate,  and  present  to  their 
users.  And,  modern  large-scale  information  systems  simply  could  not  be  built,  let  alone  maintained, 
without  database  management  systems.  So  database  management  systems  are  tools.  But  because 
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database  management  systems  are  tools  for  building  and  maintaining  other  tools— namely  informa¬ 
tion  systems— their  value  is  indirect,  and  is,  accordingly,  difficult  to  ascertain. 

Pacis  is  a  database  programming  system,  hence  it  is  a  tool  for  building  tools— information  sys¬ 
tems— and  therefore  presents  the  same  difficulties  in  determining  its  value  as  does  any  other  dbms. 
However,  pacis  differs  from  existing  database  management  systems  in  several  important  ways.  Col¬ 
lectively,  these  differences  make  the  task  of  determining  an  unambiguous  measure  of  its  value  even 
more  difficult  than  it  is  for  existing  database  management  systems.  Nevertheless,  it  is  essential  that 
a  means  of  determining  the  value  of  pacis  to  an  enterprise  be  developed,  and  that  its  efficacy  in  that 
context  be  measured  and  documented. 

The  best  way  to  demonstrate  the  value  of  a  tool  is  to  use  it  to  actually  perform  the  operation  or 
operations  it  was  intended  to  support,  measure  the  quantitative  features  of  the  process  one  expects 
the  tool  to  effect,  and  compare  these  to  a  known  baseline,  thereby  determining  the  value  of  the 
tool.  Consider:  if  one  is  going  to  determine  the  value  of  a  5 -axis  spar  mill,  one  must,  at  some  point, 
actually  use  the  machine  to  make  some  wing  spars.  One  must  also,  of  course,  make  sure  while  doing 
so  to  measure  the  amount  of  time  and  quantity  of  resources  the  mill  consumes  to  make  the  spars. 
Assuming  one  already  had  measured  the  time  and  resources  required  to  perform  the  same  task  using 
another  tool,  one  can  then  compare  the  two,  and  thereby  determine  a  relative  value. 

The  strategy  adopted  to  measure  and  document  the  value  of  pacis  exploits  the  fact  that  pacis— like 
any  other  dbms— is,  fundamentally,  a  tool  for  building  and  maintaining  information  systems.  Thus 
plans  were  formulated,  under  the  auspices  of  a  successor  program  to  the  aeip,  to  develop  a  product 
definition  management  application  system— designated  mereos— in  order  to  demonstrate  pacis 
functionality  and  value. 

The  goal  of  mereos  was  to  solve  the  multiple  bill  of  materials  (bom)  reconciliation  problem  in 
large-scale,  technically  advanced  complex  product  manufacturing  environments.  The  specific 
objectives  were  to  provide  end  users  with  the  ability  to  define,  modify,  query,  and  automatically 
maintain  relationships  between  several  distinct  boms,  specification  trees,  and  functional  architec¬ 
tures  for  a  single  product,  where  the  information  involved  is  stored  in  geographically  distributed 
heterogeneous  databases.  The  approach  was  to  use  pacis  to  demonstrate  a  product  data  management 
system  (pdm)  meeting  these  objectives. 

2.5  Selection  Process 

As  stated  earlier,  the  motivation  for  the  mereos  project  was  to  demonstrate  the  capability  and  value 
of  the  pacis  technology  and  associated  methodologies.  The  decision  to  develop  a  product  definition 
management  application  system  for  this  purpose,  as  opposed  to  any  number  of  other  applications 
one  could  develop  with  pacis,  was  based  on  several  interacting  factors  and  desiderata. 

The  most  important  criterion  determining  the  decision  was  that  the  demonstration  application 
system  provide  a  solution  to  a  problem  in  the  manufacturing  industry.  Specifically,  the  problem  had 
to  satisfy  the  following  six  criteria: 

1.  The  problem  had  to  be  well  known— i.e.,  the  problem  was  familiar  throughout  the  manu¬ 
facturing  industry. 

2.  The  problem  was  endemic  to  both  the  defense  and  commercial  sectors  of  the  manufactur¬ 
ing  industry. 

3.  In  the  case  of  the  defense  industry,  the  problem  had  to  be  visible  to  the  customer  with 
direct  (and  negative)  impacts  on  customer  life-cycle  costs. 

4.  The  problem  had  to  be  tractable  to  automation  and  Ontek  personnel  had  to  have  the  tech¬ 
nical  expertise  and  experience  required  to  solve  the  problem. 

5.  Solutions  to  the  problem  in  the  form  of  software  could  not  already  exist. 

6.  There  had  to  be  direct,  measurable,  negative  effects  on  product  cost  and  schedule  traceable 
to  the  problem,  and  the  benefits  to  cost  and  schedule  of  solving  the  problem  had  to  be 
equally  direct,  measurable  and  traceable. 
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The  multiple  bom  reconciliation  problem  stood  out  from  the  others  by  significant  measure  in  all 
the  above  considerations.  A  viable  technical  solution  to  this  problem  has  eluded  all  manufacturing 
companies,  despite  many  information  system-based  attempts  over  four  decades.  Although  there  was 
an  almost  unanimous  industry  consensus  concerning  the  importance  of  this  problem,  the  root 
cause  problem  was  not  well  understood,  nor  had  requirements  for  a  feasible  solution  been  identi¬ 
fied  in  any  systematic  way.  It  represented  the  kind  of  challenge  needed  to  further  pacis  technology 
and  methodology  developments,  as  well  as  to  demonstrate  their  combined  value. 

Almost  all  manufacturing  enterprises  producing  complex  products  also  develop  separate  engi¬ 
neering  (e-boms),  manufacturing  (m-boms),  and  logistical  or  field  support  (l-boms)— representing 
‘as-designed’,  ‘as-planned’,  and  ‘as-supported’  product  configurations— in  order  to  support  various 
engineering,  manufacturing,  and  maintenance  activities.  Further,  each  of  these  configurations  inev¬ 
itably  differ  from  one  another  both  in  form  and  content.  For  example,  in  order  to  accommodate 
empirical  producibility  constraints,  one  part  on  a  product  e-bom  is  sometimes  made  from  two  or 
more  parts  found  only  on  the  product  m-bom.  In  this  case,  the  e-bom  will  designate  only  one  com¬ 
ponent,  whereas  the  m-bom  will  designate  at  least  three.  This  kind  of  divergence  marks  the  presence 
of  a  relation  we  call  articulation.  Conversely,  it  is  sometimes  possible  to  make  several  parts  on  an 
e-bom  from  one  single  ‘progenitor’  part,  thereby  enhancing  process  or  material  utilization  effi¬ 
ciency.  In  this  case,  the  e-bom  for  that  product  will  only  designate  these  particular  components,  but 
the  m-bom  will  also  designate  the  progenitor  and  the  relationships  between  it  and  the  particular 
components.  This  kind  of  divergence  marks  the  existence  of  a  relation  we  call  factorization.  Finally, 
many  parts  on  a  product  e-bom  and  its  m-bom— frequently  entire  assemblies— never  appear  at  all  in 
its  l-bom,  because  once  assembled,  the  components  are  not  non-destructively  accessible.  This  kind 
of  divergence  signifies  the  presence  of  a  relation  we  call  integration. 

The  existence  of  these  divergences  among  boms  together  with  the  correlated  but  implicit  relations 
between  them  is  the  genesis  of  the  multiple  bom  reconciliation  problem.  That  is,  the  task  of  recon¬ 
ciling  multiple  boms  for  a  product  involves  identifying  components  that  stand  in  these  “counter¬ 
part”  relations  across  them,  and  characterizing  the  type  and  characteristics  of  those  relations. 
Establishing  counterpart  traceability  is,  in  turn,  essential  for  executing  and  propagating  the  conse¬ 
quences  of  engineering  change.  Managing  this  process  is  possibly  the  most  complex,  costly,  and 
error-prone  activity  in  any  manufacturing  enterprise.  Identifying  and  accommodating  the  ramifica¬ 
tions  of  even  a  single  modification  to  one  component  in  one  product  bom  often  requires  the  coor¬ 
dinated  expertise  of  several  speciality  disciplines,  such  as  materials  and  process,  mechanical, 
electrical,  and  software  engineering.6  The  multiple  bom  phenomenon  exacerbates  this  already  diffi¬ 
cult  problem,  since  the  impacts  of  changes  to  a  component  in  one  bom  must  be  determined  for  all 
of  its  counterparts  in  any  other  boms.  Thus,  there  is  a  direct  linkage  between  the  multiple  bom  rec¬ 
onciliation  problem  and  the  high  costs,  long  lead  times,  and  error  rates  associated  with  engineering 
change. 

Accordingly,  this  and  other  related  problems  have  received  a  great  deal  of  attention  by  the  manu¬ 
facturing  and  software  industries,  and  by  the  DoD.  There  has  been,  and  is  now,  a  literal  constella¬ 
tion  of  initiatives,  software  products,  and  standardization  efforts  designed  to  address  product 
representation  issues.7  Nevertheless,  none  so  far  have  explicitly  addressed  the  bom  reconciliation 
problem. 

The  differences  that  exist  between  these  boms  exist  for  very  good  business  reasons.  However, 
absent  the  ability  to  properly  identify  and  characterize  these  differences  by  other  than  essentially 
manual  procedures,  they  become  significant  cost,  schedule,  and  quality  drivers  for  engineering 
change  in  specific  and  all  product  operations  and  support  activities  in  general.  Moreover,  the  detri¬ 
mental  effects  of  this  problem  are  familiar  throughout  both  the  defense  and  commercial  sectors  of 

6  According  to  an  article  in  Fortune[9]  “Boeing’s  fusty  production  techniques  carry  an  enormous  price  tag.  Every  alter¬ 
nation,  even  a  seemingly  minor  one  like  moving  the  location  of  an  emergency  flashlight  holder,  consumes  thousands 
of  hours  of  engineering  time,  requires  hundreds  of  pages  of  detailed  drawings,  and  costs  hundreds  of  thousands,  if 
not  millions,  of  dollars  to  execute.”  The  flashlight  example  is  perhaps  a  bit  overstated,  although  the  point  is,  in 
essence,  valid.  This  situation  is  not  unique  to  Boeing,  nor  is  it  unique  to  the  aerospace  and  defense  industry. 

7  A  notable  example  of  these  is  pdes/step.  We  have  included  a  brief  outline  of  step  as  it  pertains  to  specific  issues 
addressed  by  the  mereos  program  in  Attachment  1:  Comments  Concerning  STEP. 
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the  manufacturing  industry.  Moreover,  these  effects  were  considered  measurable  (at  least  with 
some  effort).  We  viewed  the  problem  as  tractable  to  solution  using  pacis  technology.  Ontek  person¬ 
nel  have  had  a  great  deal  of  prior  experience  with  this  problem  domain.  A  solution  to  the  problem 
required  the  full  representational  power  of  pacis,  and  thus  was  considered  a  good  demonstration  of 
pacis  functionality.  And,  no  system  existed  that  was  specifically  designed  to  address  the  root  cause 
of  the  problem.  Finally,  the  multiple  bom  reconciliation  problem  satisfied  all  6  of  the  criteria  listed 
above.  Accordingly,  it  was  chosen  as  the  application  domain  to  use  to  demonstrate  the  new  version 

of  PACIS. 

2.6  Program  Execution  and  Evolution 

Mereos  program  execution  was  structured  into  three  distinct  phases  in  accordance  with  Enabling 
Technology  Developments  and  Demonstrations  Agile  Manufacturing  Pilot  Program  (etdd/ampp) 
project  requirements.  These  were: 

Phase  I  Technology  Feasibility  Dec  94-Dec  95 

Phase  II  Prototype  Demonstration  Jan  96-Dec  98 

Phase  III  Pilot  Production  Implementation  Jan  99-Jan  00 

The  original  mereos  Statement  of  Work  (sow)  addressed  Phase  I  and  II  tasking.  Phase  III  was  an 
option  which  required  separate  authorization  and  a  second  specific  sow.  All  three  phases  were  exe¬ 
cuted. 

The  mereos  program  was  originally  conceived  as  an  information  systems-centric  effort  to  identify 
the  requirements  for  and  demonstrate  a  solution  to  the  multiple  bom  reconciliation  problem.  While 
these  original  program  objectives  were  accomplished,  the  program  underwent  several  significant 
changes  both  in  focus  and  application  venue  during  its  execution.  We  set  out  to  solve  a  difficult  and 
long-standing  informatics  problem— we  accomplished  that,  but  also  ended  up  solving  several  enter¬ 
prise  systematics  problems  as  well,  creating  a  baseline  for  a  new  aerospace  enterprise  operating  sys¬ 
tem.  This  shift  warrants  discussion. 

2.6.1  Change  1:  An  Increase  in  Representational  Amplitude 

Preliminary  analysis  of  the  root  causes  of  the  multiple  bom  reconciliation  problem  had  been  done 
prior  to  Phase  I.  This  work  was  documented  and  subsequently  published  by  Kluwer  in  1995  as  Aspects 
of  the  Mereology  of  Artifacts  [20].  Phase  I  sow  tasking  provided  for  more  comprehensive  and  detailed 
analysis  of  the  problem,  definition  of  requirements  for  a  solution,  and  research  and  development 
activities  to  demonstrate  solution  feasibility. 

The  first  change  involved  an  increase  in  the  representational  gamut  planned  for  the  Phase  II  sys¬ 
tem,  which  occurred  as  a  result  of  Phase  I  findings.  One  specific  Phase  I  determination  was  that  an 
effective  solution  to  the  multiple  bom  reconciliation  problem  necessitated  mechanisms  for  explic¬ 
itly  representing  traceability  of  product  structures  to  so-called  ‘design  intent’— that  is,  traceability 
of  product  definition  elements,  represented  by  various  boms  and  document  trees,  to  functional, 
producibility,  and  maintainability  requirements.  This  in  turn  entailed  the  capability  to  explicitly 
represent  relevant  products  of  the  systems  engineering  Needs  Identification,  Requirements  Analy¬ 
sis,  and  Synthesis  processes,  namely  technical  requirements  and  their  relations  to  product  defini¬ 
tion  elements.  This  ‘upstream’  increase  in  representation  amplitude  was  required  to  provision 
‘downstream’  product  structure  definition  management— specifically,  engineering  change  impact 
identification  and  analysis.8 

2.6.2  Change  2:  A  Shift  in  Technical  Focus 

The  second  change  occurred  in  the  early  stages  of  Phase  II,  and  represented  a  shift  in  technical  con¬ 
ception  and  focus  rather  than  in  breadth.  Its  impetus  was  partly  due  to  the  increase  in  representa- 

8  The  need  to  explicitly  represent  technical  requirements  and  their  relationships  to  product  structures  is  discussed  in 
Section  3:  Results  Part  I,  paragraph  3.1.2. 
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tional  amplitude  mentioned  above.  But  this  shift  was  also  driven  by  a  need  to  address  an 
increasingly  exasperating  strategic  positioning  problem,  itself  symptomatic  of  what  we  call  the 
Commercial  Off-The-Shelf  (cots)  problem. 

Mereos  software  was  originally  envisioned  to  be  a  stand-alone  pdm  application  system  for  demon¬ 
strating  multiple  bom  definition  and  reconciliation  capabilities  to  end  users,  thereby  illustrating  the 
value  of  pacis  technology  to  those  stakeholders.  However,  the  increase  in  representational  scope 
required  to  completely  solve  that  problem  was  significantly  greater  than  originally  anticipated,  and 
accommodating  this  change  in  turn  forced  a  change  in  the  level  of  effort  mix  between  formal  sys- 
tematics  and  programming.  Constrained  by  fixed  resources  and  schedule  commitments,  greater 
emphasis  on  formal  systematics  had  to  be  compensated  for  by  a  reciprocal  reduction  in  software 
development.  Reducing  software  development  level  of  effort  without  sacrificing  the  core  technical 
capabilities  required  to  achieve  our  solution  demonstration  objective  necessitated  a  software  archi¬ 
tecture  change— a  change  from  an  end  user-oriented  application  to  a  developer-oriented  tool, 
focused  exclusively  on  providing  application-independent  product  structure  representation  and 
integrity  management  services.  We  retained  the  effort  to  develop  interfaces  for  visualizing  these 
structures,  and  we  of  course  retained  the  development  effort  required  to  implement  the  representa¬ 
tion  constructs  required;  this  was,  after  all,  the  critical  element  of  the  engineering  effort.  However, 
we  abandoned  sweeping  enhancements  to  the  i/o  and  foreign  system  integration  subsystems  we  had 
originally  envisioned  developing,  along  with  development  of  a  new  interpreter  and  compiler  for  the 
pacis  database  programming  language,  as  neither  of  these  would,  in  and  of  themselves,  convey  visi¬ 
ble  value  to  end  user  organizations.  Although  frustrating  at  the  time,  this  necessary  change  in  focus 
turned  out  to  have  been  very  fortuitous  indeed,  for  both  technical  and  strategic  reasons. 

One  strategic  benefit  of  the  focus  change  and  the  resulting  architectural  repositioning  was  made 
abundantly  clear  during  a  meeting  we  held  in  early  September  1996.  The  objectives  of  this  meeting 
were  to  present  to  industry  the  results  of  our  multiple  bom  problem  analysis,  demonstrate  a  proto¬ 
type  illustrating  key  elements  of  a  solution,  and  solicit  a  demonstration  site  for  Phase  III  of  the  pro¬ 
gram.  The  meeting  was  attended  by  18  organizations  including  all  the  major  aerospace  and  defense 
prime  contractors,  Deere,  and  Caterpillar.  The  results  of  this  meeting  were  simply  astonishing.  They 
were  also  ominous  from  a  business  point  of  view.  The  upshot  was  this:  no  one  seriously  challenged 
the  results  of  our  problem  analysis  nor  our  characterization  of  the  necessary  elements  for  a  solu¬ 
tion.  But  without  exception,  every  single  person  there  representing  a  potential  demonstration  site 
expressed  strong  reservations  about  using  any  “non-coTs”  solution  in  their  organizations— even  in  a 
demonstration  context.  Not  even  two  years  earlier,  these  same  companies  had  all  stated  to  us  and  to  Air 
Force  ManTech  management  that  the  multiple  bom  reconciliation  problem  was  a  major  cost,  sched¬ 
ule,  and  quality  driver,  and  that  a  solution  to  that  problem  would  be  of  great  value  to  them  and  to 
the  rest  of  industry.  Now  they  were  saying  that  such  a  solution  would  have  value  only  if  it  was  avail¬ 
able  from  a  software  industry  analog  of  KMart.9  Subsequent  to  this  exasperating  and  disappointing 

9  Air  Force  ManTech  is  not  in  the  business  of  funding  the  development  of  commercial  software.  Their  essential  mission 
is  to  identify  and  cogently  articulate  industrial  base  capability  voids  vis-a-vis  DoD  weapon  system  acquisition  and 
sustainment  needs;  define  requirements  for  solutions  to  eliminate  those  voids,  develop  fundamental  enabling  tech¬ 
nologies  and  critical  elements  of  those  solutions  where  required,  where  appropriate,  and  to  the  extent  necessary  to 
demonstrate  feasibility;  and,  to  incentivize  industry  through  programmatic  and  other  mechanisms  to  pursue  develop¬ 
ment  and  deployment  of  those  solutions.  This  is  not  to  say  ManTech  is  unconcerned  with  commercial  viability— it  is. 
Eventual  commercialization  is  one  tactic  among  many  to  disseminate  new  ManTech- sponsored  technology  and  solu¬ 
tions. 

In  that  vein,  ManTech  made  it  a  mereos  program  requirement  that  we  develop  a  comprehensive  business  strategy  for 
pacis  technology  commercialization.  We  initiated  a  strategic  planning  activity  in  early  1996  to  satisfy  that  require¬ 
ment,  and  by  May  of  1996  we  had  produced  the  first  of  several  documents  that  would  eventually  become  components 
of  a  documented  Ontek  business  plan.  This  first  document  was  an  assessment  of  relevant  environmental  factors  and 
trends,  specifically  focused  on  post-Cold  War  downsizing  of  the  defense  industrial  base,  the  transformation  of  the 
software  industry  from  a  requirements-driven  engineering-oriented  industry  to  a  market-driven  commodity  busi¬ 
ness,  and  on  the  implications— almost  all  negative— of  those  two  factors  for  pacis  technology  commercialization.  It 
was  quite  a  shock  to  see  our  predictions  concerning  attitudes  of  A&D  contractors  towards  advanced  information  sys¬ 
tems  technology  stated  in  that  May  document  be  completely  validated— with  a  vengeance— the  following  September. 

We  presented  the  first  version  of  the  complete  business  plan  to  ManTech  management  in  February  1997,  and  pre¬ 
sented  updated  versions  in  September  1998  and  March  1999. 


10 


episode,  we  attempted  to  overcome  this  Catch-22  in  meetings  with  Deere,  Caterpillar,  and  Lock¬ 
heed  Martin  Aeronautical  Systems  in  Georgia  (lmas),  and  to  convince  at  least  one  of  them  to  act  as  a 
Phase  III  demonstration  site.  We  eventually  succeeded  at  lmas,  only  because  we  were  able  to  show 
that  mereos  was  not  a  commercial  pdm  or  erp  system  competitor,  but  was  rather  an  “add-on  module” 
or  “plug-in”  to  those  systems— a  “structure  server”— that  is,  a  developer-oriented  tool ,  not  a  stand¬ 
alone  application  system.  In  other  words,  if  we  had  not  had  to  shift  our  technical  focus  and  make 
the  requisite  change  in  mereos  software  architecture,  we  would  have  not  secured  a  Phase  III  dem¬ 
onstration  site.  Nor,  to  anticipate  the  subject  of  the  third  change  described  below,  would  we  ever 
have  been  presented  with  the  opportunity  to  participate  in  the  re-design  of  a  major  prime  contrac¬ 
tor  enterprise,  or  produced  a  major  mereos  program  result— a  baseline  design  for  a  new  aerospace 
enterprise  operating  system. 

The  technical  advantages  gained  as  a  consequence  of  the  focus  change  were  equally  compelling  if 
not  more  so.  With  the  resources  allocated  to  executing  the  abovementioned  enhancements  freed 
up,  we  able  to  bring  a  great  deal  of  effort  to  bear  on  developing  the  formal  systematics  required  to 
represent  the  abstract  intentional  structures  underlying  systems  engineering  processes  and  their 
products. 

We  had,  among  other  things,  demonstrated  fully  declarative  and  directly  executable  representa¬ 
tions  of  processes  in  two  prior  versions  of  pacis.  Although  many  of  these  were  very  complicated,10 
the  structures  involved  were  nowhere  near  the  level  of  abstraction  of  those  underlying  systems 
engineering  processes  and  their  products.  And  it  was  precisely  these  structures  that  had  to  be 
explicitly  represented  if  the  increase  in  mereos  representational  amplitude  was  to  be  accomplished. 
Moreover,  systems  engineering  is  a  formal  process;  however,  most  of  the  structures  constituting  its 
conceptual  underpinnings  have  not,  as  yet,  been  formalized.  That  is,  definitive  and  detailed 
descriptions  of  systems  engineering  processes  and  products  were  readily  available,  but  suitably 
detailed  formal  characterizations  of  core  systems  engineering  entity  types  were  not.11  Nevertheless, 
formal  characterizations— technically,  formal  taxonomic  delimitations— are  essential  raw  materials 
for  implementing  computer- interpretable  representations  of  anything ,  including  these  and  other  sys¬ 
tems  engineering  entity  types.  We  accordingly  undertook  to  develop  them,  though  this  was  not  a 
trivial  undertaking  for  two  principal  reasons.  First,  all  of  the  principal  conceptual  structures  under¬ 
pinning  systems  engineering  are,  to  varying  degrees  and  in  different  guises,  active  subjects  of  cur¬ 
rent  phenomenological  and  ontological  research.  In  fact,  the  very  notion  that  intentional  structures 
are  tractable  to  formalization  at  all ,  at  least  without  eliminative  reductions  to  the  extensional  struc¬ 
tures  of  logic  and  set  theory,  is  very  recent  and  in  some  quarters  is  still  vigorously  disputed.12  Sec¬ 
ond,  we  had  begun  a  complete  re-design  of  pacis  meta-level  representation  structures— pacis 
metasystematics— just  prior  to  mereos.  Motivated  by  numerous  lessons  learned  from  our  experiences 


10  For  example,  to  demonstrate  subsumptive  integration  of  foreign  systems  in  pacis  during  the  Northrop/Air  Force  Auto¬ 
mated  Airframe  Assembly  Program  (aaap),  we  developed  a  complete  declarative  representation  of  the  entire  ims  data¬ 
base  management  system  schematics— its  representation  structures,  data  definition,  and  data  manipulation  language 
operators— and  we  used  this  implementation  metascheme  as  the  basis  for  a  pacis  subsystem  that  automatically  gener¬ 
ated  representations  of  ims  database  definitions,  and  another  that  generated- hoc  queries  against  them  during  execu¬ 
tion  of  pacis  process  representations.  Ims  is  notoriously  complicated;  as  one  Northrop  database  administrator  and 
systems  programmer  once  remarked:  “If  you  can  ‘do’  ims,  you  can  do  anything.”  Well,  not  quite:  you  can’t  ‘do’  systems 
engineering  requirements  traceability  management  automation,  for  example. . . 

11  Examples  of  these  are  entity  types  such  as  requirement;  derivation,  allocation,  and  synthesis  (the  relations),  and 
Measure  of  Effectiveness  (moe),  This  absence  of  formalization  despite  mature  practice  is  analogous  to  the  situation  in 
mathematics.  Mathematics  as  a  formal  enterprise  is  at  least  2,400 years  old,  but  systematic  efforts  to  formalize  Number 
itself  only  began  in  the  late  19th  century.  Among  other  things,  efforts  to  formalize  the  foundations  of  mathematics 
led  to  the  development  of  electronic  computing  machines.  This  analogy  demonstrates  that  a  great  deal  of  both  prac¬ 
tical  and  theoretical  work  can  be  accomplished  without  reflective  formalization,  but  implementing  intentional  pro¬ 
cesses  in  terms  of  computer  programs  can’t  be. 

12  For  that  matter,  phenomenology  as  a  distinct  philosophical  discipline  is  itself  less  than  120  years  old,  and  formal 
ontology  is  only  100.  The  criticisms  of  so-called  “artificial  intelligence”  leveled  by  Hubert  Drefus  and  his  fellow-trav¬ 
elers  are  an  example  of  one  dimension  of  the  controversy  over  the  formalizability  of  intentional  structures.  Our 
favorite  counter  to  certain  of  these  arguments  is  a  quip  by  John  Searle:  “Of  course  the  background  can  be  represented. 
Here  goes:  ‘the  Background’.”  [18.1]  Although  unhelpful  from  a  software  engineering  perspective,  it’s  clever  and 
funny. 
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with  the  prior  version  of  the  system,  the  aim  of  this  effort  was  to  put  the  metasystematics  on  new 
and  completely  self- applicative  foundations,  and  to  systematically  re-derive  the  principal  schematic 
elements  of  the  representation  system  from  those.13 

Metasystematic  structures  are  by  definition  the  most  abstract  possible  and  self- applicative  meta¬ 
structures  are  the  most  intricate;  they  are  the  elements  of  pure  autothetic  form.  It  is  accordingly 
necessary  from  a  practical  standpoint  to  inform  metasystematic  efforts  with  concrete  and  suitably 
illustrative  examples.  It  is  also  a  formal  necessity  to  partly  evaluate  the  results  of  such  efforts  in 
terms  of  their  capabilities  to  explicate  these  and  any  other  possible  exemplars.  The  conceptual 
structures  of  systems  engineering  were  an  excellent  addition  to  the  examples  we  had  already  been 
using  for  this  purpose.14  Their  intimate  relationships  to  product  and  process  structures  meant  they 
were  germane  to  the  other  examples  we  were  using  to  inform  this  endeavor.  However  the  fact  they 
are  essentially  intentional  meant  they  were  very  different  in  kind  from  the  others,  and  the  need  to 
systematically  explicate  these  taxonomic  ‘gaps’  in  terms  of  metasystematic  constructs  represented  a 
decidedly  non-trivial  ‘stretch’  for  our  efforts.  But  it  was  the  differences  between  the  three  example 
sets  that  was  actually,  in  the  final  analysis,  the  big  payoff— or  rather,  the  solution  to  the  problem  of 
developing  the  requisite  metasystematics  to  subsumptively  and  systematically  explicate  these  differ¬ 
ences  was.  The  solution  to  this  problem,  which  we  call  the  structure  abstraction  or  structure  factorization 
solution,  represented  a  major  technical  advance  achieved  by  the  program,  and,  as  we  will  see 
shortly,  it  provisioned  us  to  take  advantage  of  a  major  strategic  opportunity  as  well. 

None  of  this  work  was  visible  to  any  pacis  stakeholder  except  the  formal  team;  it  is  the  nature  of 
abstractions  to  be  invisible  except  through  their  concrete  instances.  However,  the  new  metastruc¬ 
tures  greatly  enhanced  our  understanding  of  the  structures  underlying  systems  engineering,  system- 
atics,  and  artifacts,  and  that  deeper  understanding  was  manifested  to  others  in  our  abilities  to 
clearly  articulate  the  root  causes  of  and  the  necessary  characteristics  of  solutions  to  problems  like 
the  multiple  bom  problem. 

2.6.3  Change  3:  Mereos  Phase  III,  Redefined 

The  third  change  was  both  a  radical  shift  in  focus  and  a  major  change  in  venue.  It  transformed 
mereos  from  an  information  systems  program  focused  on  tactical  product  representation  problems 
into  an  enterprise  architecture  program,  focused  on  the  strategic  issues  involved  in  designing  a  new 
aerospace  enterprise  operating  system. 

We  mentioned  earlier  that  after  lengthy  discussions  with  several  organizations,  lmas  had  agreed 
to  serve  as  the  mereos  Phase  III  demonstration  site.  This  agreement  was  reached  in  mid- 1997.  Dur¬ 
ing  1998  we  held  a  series  of  discussions  with  lmas  personnel  in  Marietta  to  solidify  the  details  of 
this  agreement,  to  select  a  particular  program  to  host  the  Phase  III  demonstration,  and  to  define 
specific  objectives,  mutual  responsibilities,  and  qualification  criteria  for  the  demonstration  system. 
Over  the  course  of  these  discussions,  our  understanding  of  lmas  product  definition  and  representa¬ 
tion  practices  deepened,  as  did  our  familiarity  with  two  related  information  systems  implementa¬ 
tion  initiatives.  Participating  lmas  personnel  also  gained  a  comprehensive  understanding  of  mereos 
technology  and  its  relationships  to  those  practices  and  initiatives. 

Like  any  other  classical  aerospace  prime,  many  lmas  processes  and  associated  practices  were  divi¬ 
sionalized  along  programmatic  lines.  These  included  the  Product  Realization  process,  many  of  its 
subprocesses— notably  Product  Definition— and  its  related  product  representation  practices. 


13  The  most  critical  metasystematic  structures  were  the  taxon  and  concrescence  taxa  and  their  primary  noumenal  deriv¬ 
atives  occurrent  and  continuant.  The  principal  schematic  elements  of  representation  system  are  entity  and  inten- 
tionality.  These  are  derivatives  of  the  primary  noumenal  taxa,  and  they  constitute  the  superstructure  of  the 
representation  system. 

14  The  two  example  sets  we  had  been  using  before  this  change  occurred  were  complex  product  and  process  structures 
and  those  of  biological  systematics— the  latter  being  the  most  well-developed  and  explanatorily  powerful  we  know 
of.  In  fact,  the  pacis  metasystem  is  a  generalization  and  self- applicative  abstraction  of  biological  systematics.  It  is  a 
generalization  because  our  representations  must  encompass  more  than  living  things.  It  is  an  abstraction  in  that  such 
things  as  similarity,  delimitation,  and  identification  (and  their  numerous  variants)  are  all  taxa,  and  it  is  self- applica¬ 
tive  in  that  taxon  is  itself  also  a  taxon.  The  relevant  corners  of  the  metasystem  (the  phylogenetic  taxonomy  of  simi¬ 
larity  and  that  of  taxon  itself)  are  depicted  by  Figures  31  and  28  in  Attachment  2,  respectively. 
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Extreme  differences  in  program  age  had  also  brought  about  even  greater  divergences  between  each 
program-specific  variant  of  these  processes,  well  beyond  the  norm.  For  example,  c-130  is  a  very 
mature  program;  deliveries  of  the  first  production  aircraft  had  been  made  in  December  1956.  The 
c-130  product  definition  is  accordingly  historically  deep  and  systemically  broad,  at  that  time 
encompassing  42  years  of  engineering,  countless  variants,  models,  and  options— many  of  which 
were  still  actively  being  produced— and  it  also  included  the  c-130j:  “an  entirely  new  airplane.”  In 
contrast,  f-22  was  still  in  pre-first  flight  emd.  Unsurprisingly,  c-130  Product  Realization  processes— 
especially  c-130  Product  Definition  and  engineering  release  processes— had  very  little  in  common 
with  their  f-22  counterparts  beyond  superficial  similarities  due  to  shared  materiel,  finance,  and  hr 
functions.  Most  importantly  to  us,  their  product  representation  practices  and  product  data  conven¬ 
tions  differed  dramatically,  and  so  did  the  information  systems  each  program  used. 

An  initiative  to  establish  a  common  Product  Definition  process  across  programmatic  lines  had 
been  underway  for  some  time  prior  to  our  engagement  with  lmas.  Impelled  by  looming  f-22  and 
c-130  j  production  program  cost  reduction  needs,  this  initiative  had  adopted  the  approach  of  creat¬ 
ing  a  common  process  via  use  of  a  commercial  pdm  software  package.  In  early  1998  a  second  initia¬ 
tive  to  establish  common  Product  Delivery  and  supporting  infrastructure  processes  had  also  been 
formally  launched.  Also  impelled  by  f-22  and  c-130j  program  needs,  this  initiative  was  focused  on 
creating  commonality  via  use  of  a  commercial  erp  software  package.  These  two  initiatives  were 
similar  in  several  respects.  Both  were  mandates  of  Lockheed  Martin  Aeronautics  Sector  headquar¬ 
ters;  lmas  was  their  first  target  implementation  site  (the  other  sector  companies  were  to  follow); 
each  was  predicated  on  an  explicit  “cots  only”  policy;  and  neither  was  going  to  be  capable  of 
addressing  real  lmas  product  representation  needs— although  this  latter  point  was  only  understood 
by  a  small  cadre  of  lmas  cognoscenti,  and  was  not  generally  recognized  by  either  of  the  teams  lead¬ 
ing  these  two  initiatives  or  by  lmas  and  Aeronautics  Sector  management. 

In  light  of  this  situation,  two  facts  had  become  increasingly  clear  at  this  stage  of  our  discussions 
with  lmas.  The  first  was  that  demonstrating  the  mereos  solution  to  complex  aerospace  product  repre¬ 
sentation  needs  and  requirements  would  not  constitute  much  value  for  lmas.  The  second  was  that 
exploiting  our  command  of  the  relevant  product  representation  requirements  to  support  their  enter¬ 
prise  process  improvement  and  related  information  systems  implementation  initiatives  would  con¬ 
stitute  value  for  lmas. 

To  help  address  the  product  representation  capability  shortcomings  of  these  initiatives,  and  to 
contend  with  the  impedances  to  the  mereos  Phase  III  demonstration  objectives  presented  by  them, 
we,  together  with  our  internal  lmas  sponsors,  undertook  a  vigorous  and  concerted  effort  to  bring 
the  relevant  requirements  to  the  attention  of  all  concerned.  To  accomplish  this  we  conducted  a  series 
of  presentations  to  demonstrate  the  specifics  of  complex  product  representation  needs  and  require¬ 
ments  to  both  teams;  we  wrote  and  distributed  documents  outlining  these;  and  we  demonstrated 
software  to  illustrate  key  capabilities  that  any  candidate  solution  offered  by  either  of  these  initia¬ 
tives  would  necessarily  have  to  provide.  Thus  all  throughout  1998,  we  played  the  role  of  Product 
Definition  and  Product  Representation  process  architects,  emphasizing  our  command  of  the  relevant 
requirements,  and  de-emphasizing  our  capabilities  to  produce  information  system  solutions  to 
those  requirements,  except  as  a  vehicle  for  demonstrating  the  feasibility  of  developing  systems  to 
provide  the  requisite  capabilities. 

During  1998  we  had  also  taken  on  an  architectural  mantle  in  another  lmas  initiative  as  well,  puta¬ 
tively  unrelated  to  the  Sector-mandated  pdm  and  erp  initiatives.  Lmas  leadership  had  started  an 
enterprise  productivity  (ep)  initiative  in  mid- 1997,  motivated  both  by  programmatic  and  by  strategic 
needs  to  enhance  lmas  competitiveness  by  improving  enterprise  process  efficiencies  and  overall 
effectiveness.  Cognizant  of  our  prior  work  on  similar  programs  in  other  companies,  the  leader  of 
the  lmas  ep  initiative  brought  us  in  to  assist  in  developing  a  strategic  plan  for  governing  and  execut¬ 
ing  the  lmas  ep  program.  We  produced  two  substantive  contributions  to  the  program  as  a  result  of 
this  effort.  First,  we  developed  a  formal  strategic  plan  for  the  ep  program  which  was  explicitly  linked 
and  thus  directly  traceable  to  both  the  lmas  company  and  Aeronautics  Sector  strategic  business 
plans.  The  principal  tactical  element  of  that  strategic  plan  was  a  program  to  develop  and  deploy  a 
new  lmas  enterprise  architecture,  and  the  second  product  we  produced  was  a  detailed  plan  for  that 
program. 
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Both  of  these  activities  were  heavily  dependent,  albeit  in  different  ways,  on  the  metasystematics 
we  had  developed  to  support  mereos  representations  of  the  abstract  intentional  structures  underly¬ 
ing  systems  engineering  processes  and  their  products.  In  fact,  we  would  not  have  been  able  to  exe¬ 
cute  either  of  these  architectural  efforts  without  first  having  had  these  results  in  hand.  The  Product 
Definition  and  Representation  needs  and  requirements  analyses  we  presented  to  the  pdm  and  erp 
teams  were  developed  using  our  formalization  of  systems  engineering  methods,  and  they  were 
framed  in  terms  of  those  structures.  The  formal  scheme  used  to  define  the  ep  strategic  plan  and  its 
explicit  traceability  to  the  lmas  and  Sector  strategies  was  a  direct  result  of  our  applying  a  generaliza¬ 
tion  of  systems  engineering  methods  to  strategy  development.  And  most  significantly,  our  approach 
to  developing  the  lmas  enterprise  architecture  was  predicated  on  the  use  of  new  formal  methods, 
based  on  the  synthesis  of  biological  systematics  and  systems  engineering  we  had  developed  as  a 
result  of  our  effort  to  re-design  the  pacis  metasystem. 

It  had  also  become  obvious  to  the  most  casual  of  observers  as  a  result  of  our  activities  during  1998 
that  the  original  objectives  for  Mereos  Phase  III  were  going  to  have  to  be  re-structured  to  accom¬ 
modate  lmas  realities.  Then  a  truly  fortuitous  event  occurred:  a  new  lmas  president  was  appointed 
in  early  1999,  and  his  personal  mission  was  to  “re-invent”  lmas.  The  opportunities  presented  by  this 
leadership  change  to  all  mereos  program  stakeholders  were  utterly  clear.  The  new  president  was 
briefed  on  the  proposed  enterprise  architecture  program  and  our  envisioned  role  in  it  in  early 
March.  We  consulted  with  cognizant  Air  Force  personnel  to  discuss  our  participation  in  this  pro¬ 
gram  under  Mereos  Phase  III  auspices.  Lmas  agreed  to  match  Air  Force  funding  to  support  the 
changes  and  increases  in  Phase  III  tasking,  and  in  May  of  1999  the  Lmas  Enterprise  Architecture  Pro¬ 
gram  (leap)  was  officially  launched,  fully  supported  by  an  Ontek  team.  This  last  and  most  far  - 
reaching  of  the  major  changes  marking  the  evolution  of  the  mereos  program  had  occurred. 
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The  ship  wherein  Theseus  and  the  youth  of  Athens  returned  had  thirty  oars,  and  was 
preserved  by  the  Athenians  down  even  to  the  time  of  Demetrius  Phalereus,for  they  took 
away  the  old  planks  as  they  decayed,  putting  in  new  and  stronger  timber  in  their  place, 
insomuch  that  this  ship  became  a  standing  example  among  the  philosophers,  for  the 
logical  question  of  things  that  grow;  one  side  holding  that  the  ship  remained  the  same, 
and  the  other  contending  that  it  was  not  the  same. 

Plutarch,  The  Life  ofTheseus 


3 

RESULTS  PART  I: 

Product  Structure  Definition  and  Management 


The  two  primary  mereos  program  objectives  were  first,  to  identify  the  root  causes  of  the  multiple 
bom  reconciliation  problem  and  define  the  requirements  for  a  solution,  and  second,  to  prove,  via 
demonstration,  the  feasibility  of  developing  a  system  to  implement  that  solution.  Both  of  these 
objectives  were  achieved.  That  is,  we  produced  a  rigorous  and  detailed  definition  of  formal  require¬ 
ments  for  a  product  data  management  system— one  capable  of  addressing  the  real  needs  of  both 
aerospace  and  defense  contractors  and  other  manufacturing  enterprises  that  produce  complex, 
technically  advanced  products.  We  also  developed  and  demonstrated  software  that  proved  the  feasi¬ 
bility  of  creating  a  system  that  satisfies  those  requirements,  thereby  also  achieving  our  aim  of  dem¬ 
onstrating  the  value  of  pacis  technology  in  a  strategically  visible  business  context. 

But  success  defined  in  terms  of  achieving  programmatic  objectives  is  not  necessarily  coincident 
with  delivering  value  to  stakeholders.  Nor  is  the  value  realized  by  achieving  one  objective  necessar¬ 
ily  equal  to  that  of  the  others.  In  fact,  for  reasons  we  will  briefly  sketch  now,  the  formal  require¬ 
ments  definition  we  produced  is  of  much  greater  potential  value  to  industry— and  thus  to  ManTech 
and  DoD— than  the  software  we  built  and  demonstrated. 

Consider  the  following  facts.  Every  major  prime  contractor  has  developed  and  implemented  at 
least  one  product  data  management  system.  Most  have  created  and  used  several.  Many  “commercial- 
off-the-shelf  ”  (cots)  pdm  systems  have  been  available  for  some  time.  Every  major  prime  contractor 
has  licensed  and  is  using  at  least  one  of  those  as  well  Despite  this  abundance  however,  familiar  and 
long-standing  product  representation  problems  continue  to  hinder  industry  efforts  to  lower  costs, 
improve  quality,  and  reduce  cycle  time.  The  multiple  bom  reconciliation  problem  is  simply  one 
illustrative  example  of  these  problems.  Given  these  facts,  it  should  be  obvious  that  what  aerospace 
and  defense  contractors  and  their  commercial  peers  do  not  need  is  yet  another  pdm  system.  What 
they  do  need  is  an  effective,  implementable,  sustainable,  and  total  solution  to  all  of  the  requirements 
deriving  from  their  product  representation  needs.  And  it  is  also  a  fact  that  no  such  solution  exists, 
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notwithstanding  the  claims  of  some  software  vendors  to  the  contrary.  Moreover,  a  pdm  system  will 
never  constitute  a  complete  solution  to  product  representation  requirements:  regardless  of  its  capa¬ 
bilities,  an  information  system  is  only  one  element  among  many  necessary  to  realize  a  total  solution 
to  those  requirements.15  Thus  even  if  a  system  with  the  requisite  capabilities  to  address  real  product 
representation  needs  existed— and  it  doesn’t— or  even  if  the  mereos  program  had  produced  a  com¬ 
mercially  available  production  version  of  such  a  system— and  this  was  not  a  mereos  program  objec¬ 
tive-such  a  system  would  only  constitute  a  partial  solution. 

Several  factors  are  impeding  development  of  a  truly  effective,  albeit  partial,  information  system 
solution.  These  in  combination  with  others  are  inhibiting  development  of  a  total  solution.  None  are 
mere  programming  problems.  Nor  for  that  matter  are  they  ultimately  methodological,  organiza¬ 
tional,  or  even  strategic  issues,  although  many  of  these  are  symptomatic  of  the  underlying  root 
causes.  The  truly  operant  impediments  are  conceptual— they  are  formal  process  problems.  Specifically, 
they  are  Product  Representation  and  superordinate  Product  Realization  architecture  problems.  To  be 
precise,  the  two  greatest  obstacles  blocking  development  of  both  a  total  enterprise  solution  and  an 
effective  information  system  solution  are  the  absence  of  cogent  requirements  definitions  and  the 
consequent  lack  of  implementable  balanced  designs  for  these  processes. 

In  the  light  of  these  facts,  it  should  be  clear  why  our  development  of  an  experimental  pdm  appli¬ 
cation  to  demonstrate  an  entirely  new  kind  of  information  system,  no  matter  how  powerful,  repre¬ 
sents  little  strategic  value  to  external  mereos  program  stakeholders.  It  should  be  equally  clear  why  a 
comprehensive  needs  analysis  and  systematic  requirements  definition  for  the  Product  Representa¬ 
tion  process  does  constitute  significant  value  to  those  stakeholders— it  is  impossible  to  provision  a 
poorly  understood  process  with  an  effective  information  system,  and  it  is  counterproductive  to 
automate  the  data  creation  and  management  activities  of  a  flawed  one. 

Real  complex  product  representation  needs  primarily  consist  in  structure  multiplicity,  other  spe¬ 
cific  dimensions  of  representational  amplitude,  and  concomitant  correspondence  and  integrity.  The 
critical  requirements  comprise  17  specific  metastructures,  3  classes  of  functional  capabilities,  and  2 
primary  supervening  organizational  and  enterprise  process  requirements.  As  far  as  we  have  been 
able  to  ascertain,  these  results  constitute  the  first  formal  systematic  explication  of  complex  product 
representation  needs  and  requirements  ever  produced  that  is  explicitly  focused  on  meta-level  struc¬ 
tures  and  situated  in  a  total  enterprise  operating  system  context.  Because  of  its  intrinsic  value  to 
industry,  and  thus  ultimately  to  ManTech  and  DoD,  this  needs  analysis  and  requirements  definition 
is  the  focus  of  our  presentation  here. 

3.1  Product  Representation  Needs 

Product  Realization  is  the  primary  enterprise  mechanism  for  delivering  customer  value  and  is,  accord¬ 
ingly,  the  core  process  of  any  manufacturing  enterprise.  This  process  constitutes  a  technical  and 
customer-centric  axis  of  Solution  Realization,  one  of  the  three  major  enterprise  processes,  and  it 
is  aligned  with  the  product  life  cycle  in  ways  we  only  touch  on  here.  The  primary  external  inputs  to 
Product  Realization  are  technical  customer  needs.  Its  principal  outputs  are  product/process  systems 
exemplifying  the  performance  and  effectiveness  characteristics  required  to  satisfy  those  needs.  As 
depicted  in  the  figure  on  the  following  page,  there  are  three  major  Product  Realization  subpro¬ 
cesses:  Product  Definition ,  Development  (sometimes  called  Production  or  Delivery),  and  Support.  The 
first  two  of  these  directly  constitute  phases  in  the  product  life  cycle.  Product  Support  does  not,16 
although  this  does  not  impact  the  product  structure  definition  and  management  issues  that  concern 
us  here. 


15  Other  notable  elements  of  a  total  product  representation  solution  are  suitably  capable  Product  Representation  and 
Realization  processes,  properly  aligned  organizations  to  optimally  execute  and  govern  those  processes,  and  requisite 
infrastructure  for  provisioning  them  both.  These  and  other  crucial  enterprise  operating  system  elements  are  dis¬ 
cussed  in  Section  4:  Results  Part  II. 

16  At  least  as  classically  understood  and  as  executed  by  manufacturing  enterprises.  Product  Support  is  a  logistics-centric 
cut  through  customer  processes  involving  use  of  manufacturing  enterprise  products.  Interdiction  [using  an  f-i6]  and 
Harvesting  [using  a  Deere  9750  sts  combine]  are  examples  of  customer  processes  that  can  be  instrumentalized  by 
these  products.  Spareing,  which  is  classically  executed  by  the  producing  manufacturing  enterprise,  is  a  prosaic  example 
of  a  logistics-centric  cut  through  both  of  these. 
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Figure  2.  Product  Realization  Process  Elements 


The  principal  inputs  to  Product  Definition  are  instrumentality  capability  voids— technical  needs. 
Its  primary  outputs  are  complete  prescriptive  system  delimitations— Total  definitions’— verifiably 
representing  technical  solutions  to  the  requirements  deriving  from  those  needs.  The  principal 
inputs  to  Product  Development  are  descriptive  and  executable  elements  of  product  definitions 
called  “build  packages.”  Its  primary  outputs  are  deliverable  systems  demonstrably  realizing  those 
definitions  and  related  documentation.  Aside  from  the  deployed  products  themselves,  Product  Sup¬ 
port  inputs  are  diverse  but  mainly  comprise  logistics  (spares,  test  equipment,  etc.)  and  product  def¬ 
inition  elements  collectively  called  “tech  pubs.”  These  latter  generally  fall  into  two  groups: 
descriptions  of  product  operations  and  executable  sustainment  definitions.  Its  principal  outputs  are 
product  systems  in  states  of  operational  readiness  (including  requisite  provisioning),  improvement 
requests  and  defect  identifications,  and,  ultimately,  product  system  retirements  or  disposals. 

Even  these  superficial  characterizations  should  make  it  clear  that  product  data  are  the  primary 
information  assets  required  to  provision,  execute,  and  govern  the  Product  Realization  process.  All 
Product  Realization  subprocesses  and  activities  both  require  and  generate  specific  types  of  product 
data.  Moreover,  these  data  are  utterly  pervasive.  With  few  exceptions,17  all  manufacturing  enterprise 
processes  and  activities  depend  on  product-related  data  in  some  way,  albeit  to  differing  degrees, 
and  all  generate  product-related  data,  though  of  diverse  and  in  some  cases  only  indirectly  con¬ 
nected  kinds.  Thus  the  efficiency  and  effectiveness  of  all  enterprise  processes  are  intricately  but 
nonetheless  directly  related  to  product  data  completeness,  fidelity,  and  availability— and,  conse¬ 
quently,  so  is  the  strategic  vitality  of  these  enterprises.  Given  the  nature  of  manufacturing  and  the 
central  role  of  the  Product  Realization  process  in  such  enterprises,  this  is  hardly  surprising. 

Product  definitions  comprise  both  the  integrating  superstructure  for  product  data  and  the  schematic 
underpinnings  of  all  other  enterprise  data— they  are  the  conceptual  cornerstones  of  the  manufac¬ 
turing  enterprise.  Representing  product  and  other  related  entity  types,  their  structures,  variants, 
attributes,  and  relationships  among  these,  product  definitions  are  the  premier  information  assets  of 
any  manufacturing  enterprise.  For  organizations  that  create  complex  technically  advanced  products, 
they  are  also  major  strategic  assets,  and  for  aerospace  and  defense  contractors,  they  are  capital 
deliverable  products  as  well,  requiring  years  of  effort  by  legions  of  skilled  people  to  produce,  and 
substantial  infrastructures  to  maintain.  Engineering  defects— flaws  or  deficiencies  in  product  defi¬ 
nition  content— have  serious  operational,  economic,  and  hence  strategic  consequences  for  product 
users  and  for  the  manufacturing  enterprises  that  produce  them.  Formal  representation  defects— 
flaws  or  deficiencies  in  product  definition  informatics— also  have  severe  impacts  on  Product  Realiza¬ 
tion  process  performance  and  effectiveness.  Unlike  engineering  defects,  informatic  deficiencies  are 


17  Certain  extrinsic  regulatory  compliance  activities  such  as  eeoc  reporting  would  be  one  example. 
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invisible  to  product  users  and  only  obliquely  visible  to  producers,  as  they  tend  to  be  obscured  by 
the  very  visible  and  negative  effects  of  several  pervasive  Product  Realization  problems.  Engineering 
release,  logistics  integration  (so-called  “supply  chain  integration”)  and  engineering  change  propaga¬ 
tion  are  three  notable  and  inter-related  examples  of  these  problems.  Informatic  deficiencies  lie  at 
the  center  of  them  all,  and  many  others  besides. 

Thus  even  at  this  shallow  level  of  analysis,  two  intrinsic  elements  of  Product  Realization  immedi¬ 
ately  stand  out  as  critical  enablers  of  enduring  superior  capability.  The  first  is  the  process  of  produc¬ 
ing  and  sustaining  product  definitions— call  that  the  Systems  Engineering  process.  The  second  is  the 
process  of  producing  and  sustaining  the  informatic  metastructures  and  systems  that  frame  product 
definitions,  which  we  will  call  the  Product  Representation  process. 

As  we  conceive  of  it  here,  the  Systems  Engineering  process  is  Product  Definition.  More  precisely, 
it  is  a  specific  configuration  of  that  process  tailored  for  rigorously  defining  complex  products  that 
typically  require  substantial  capital  investment  and  novel  technology  to  develop,  and  extensive 
infrastructure  to  use  and  sustain,  usually  over  decades  of  service  life.  But  Systems  Engineering  is, 
nevertheless,  the  Definition  subprocess  of  the  Product  Realization  process.  The  Product  Represen¬ 
tation  process  is  not,  in  contrast,  a  Product  Realization  subprocess— it  is,  rather,  a  particular  variant 
of  that  entire  process.  That  is,  invoking  the  context  of  enterprise  architectures,  Representation  is  the 
Product  Realization  process  itself  applied  to  informatics.18  Its  principal  products  are  information  sys¬ 
tems—  instrumentalities  for  provisioning  decision-making  processes;  tools  of  purposeful  thought. 
Product  Representation  is  simply  Representation  applied  to  product  informatics,  and  its  information 
systems  products  are  tools  for  provisioning  intentional  activities  involved  in  the  Product  Realization 
process,  including— but  certainly  not  limited  to— Systems  Engineering  analysis,  synthesis,  and  evalu¬ 
ation. 

A  great  deal  of  focused  expertise  has  been  brought  to  bear  over  the  years  to  define  Product  Real¬ 
ization  as  a  formal  process.  The  Systems  Engineering  process  in  particular  is  very  well  understood 
and  thoroughly  codified,  as  the  large  body  of  good  quality  specifications  and  textbooks  describing 
it  demonstrates.  On  the  other  hand,  understanding  of  Product  Representation  as  a  formal  process  in 
its  own  right  is  not  mature,  although  several  efforts  to  ameliorate  this  have  yielded  considerable 
progress  and  have  produced  significant  benefits  for  industry.19  But  the  continued  existence  of  prob¬ 
lems  such  as  multiple  bom  reconciliation  are  symptomatic  of  the  fact  that  at  least  some  core  product 
representation  needs  have  not  yet  been  cogently  identified  and  articulated— a  least  not  to  the 
extent  necessary  to  enable  viable  solutions  to  these  problems  to  be  developed.20  We  will  now  turn 
our  attention  to  these  needs. 


18  Actually,  Representation  is  Solution  Realization  applied  to  informatics;  and  is  therefore  a  variant  of  that  process  as  is 
Product  Realization.  However  the  systematic  complexities  of  the  distinctions  between  these  two  processes  need  not 
concern  us  here. 

19  Pdes/step  [13]  is  a  notable  example.  This  family  of  standardization  efforts  has  produced  great  deal  of  quality  work 
aimed  at  standardizing  product  definition  data  to  facilitate  its  exchange  among  differing  information  systems. 

20  To  be  fair,  many  product  representation  problems  sit  directly  on  the  shoulders  of  long-standing  and  elusive  ontologi¬ 
cal  problems;  it  is  not  surprising  some  of  these  are  so  resistant  to  solution.  For  example,  the  nature  of  Part-Whole  and 
Dependence  relations  (Assembly^Component  and  Part^Material  relations  in  boms)  were  studied  in  detail  by  Aristo¬ 
tle,  but  formalizations  of  these  useful  for  producing  product  representation  systems  were  only  developed  very  recently 
[20].  The  nature  of  change,  substance,  and  the  status  of  artifacts  are  subjects  of  long-standing  philosophical  debate,  as 
is  illustrated  by  the  quote  from  Plutarch  at  the  beginning  of  this  section.  Engineering  change  impact  identification, 
propagation,  and  traceability  management  problems  are  directly  related  to  these  questions.  There  is  in  fact  a  much 
closer  relationship  between  product  representation  problems  and  some  protracted  philosophical  issues  than  one 
might  initially  suspect,  and  some  philosophical  work  to  address  these  (though  not  as  much  as  one  would  hope)  is 
directly  relevant  and  helpful.  It  is  certainly  possible  to  build  an  pdm  system  without  understanding  the  intricacies  of 
these  and  other  related  issues;  people  have  done  so  for  years.  It  is  not  possible  to  produce  one  that  solves  the  prob¬ 
lems  we  are  concerned  with  here  without  such  an  understanding  and  an  ability  to  encode  that  understanding  in  a  pro¬ 
gramming  language.  You  can’t  hand-wave  a  c++  compiler:  you  can’t  represent  something  you  don’t  know  exists  in  a 
struct  statement,  and  you  can’t  automate  a  process  you  don’t  understand  in  c++  code. 
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3.1.1  Structure  Multiplicity 

Product  definitions  are  representations  of  artifact  types.  Artifacts  are  entities  which  are  designed  and 
created  by  certain  specific  intentional  processes,  or  which  are  instrumentalities  used  by  intentional 
agents  to  execute  processes,  or  both.  Types  are  taxa;  groups  of  related  entities.  Representations  are 
artifacts  of  intentional  processes  that  objectify— i.e.,  present— other  entities  to  intentional  agents. 
Many  kinds  of  product  data  are  representations  of  artifact  taxa.  Some  represent  individual  members 
of  artifact  taxa.  Process  architectures  depicted  by  functional  flow  diagrams  and  correlated  synthesis 
architectures  represented  by  e-boms,  m-boms,  and  l-boms  are  common  examples  of  the  former.  Indi¬ 
vidual  physical  architectures  represented  by  serialized  “as-built”  and  “as-repaired”  boms  are  exam¬ 
ples  of  the  latter.  Both  kinds  are  of  interest  to  us  here. 

It  is  an  empirical  matter  of  fact  that  a  given  product  can,  and  almost  invariably  does,  actually 
instantiate  multiple  coincident  and  divergent  structural  configurations.  That  is,  there  is  no  such 
thing  as  “the”  structure  of  an  artifact  type  or  even  of  a  particular  individual  artifact,  if  by  the  term 
“the”  one  means  a  single  incontingent  and  invariant  structure.  It  is  a  formal  matter  of  fact  that  the 
origins  of  many  divergences  among  these  configurations  are  contrasts  among  relations  between 
artifacts  and  concrete  processes.  It  is  consequently  a  pragmatic  matter  of  fact  that  the  differences 
between  these  exist  for  both  formal  and  practical  reasons.  Hence  it  is  an  analytic  fact  that  these 
classes  of  divergence  cannot  be  explicated  in  terms  of  mere  representational  conventions,  or  differ¬ 
ences  among  ‘views/  And  finally,  it  is  an  effective  fact  that  they  also  comprise  one  major  root  cause 
of  product  realization  and  representation  problems— most  notably  the  steep  costs,  long  lead  times, 
and  high  error  rates  associated  with  propagating  engineering  change  in  complex  manufacturing 
environments.  We  will  support  and  illustrate  these  arguments  by  first  enumerating  some  represen¬ 
tative  types  of  structural  configurations,  and  then  follow  that  with  some  specific  examples  of  dif¬ 
ferences  among  them.  Note  however  that  the  phenomenon  of  structure  multiplicity  is  much 
broader  and  more  complicated  than  is  conveyed  by  these  specific  examples,  and,  accordingly,  so  are 
its  representational  consequences  and  the  corresponding  need. 

3 . 1 . 1 . 1  Representative  Structure  Types 

All  complex  product  systems  exemplify  at  least  four  distinct  and  specific  structural  configurations: 
nominal  constructive,  sustainment,  and  effective  configurations.  Each  of  these  differ  from  the  others  both 
in  form  and  in  content.  Effective  configurations  are  determined  by  application  contexts  and  are, 
accordingly,  related  to  processes  in  which  product  systems  are  used  in  instrumental  capacities  to 
execute  these  processes.  The  first  three  configurations  are  correlated  to  and  conditioned  by  prod¬ 
uct  life  cycle  phases,  and  are,  accordingly,  related  to  major  Product  Realization  subprocesses  in  ways 
we  will  describe  in  more  detail  below. 

I  Nominal  Configurations  and  E-Boms 

The  e-bom  for  a  product  system  such  as  the  F-22  represents  its  abstract  physical  architecture.  This 
architecture  defines  an  instrumentality  for  realizing  the  operational  axis  of  the  F-22  functional  archi¬ 
tecture  and  its  attendant  performance  and  effectiveness  requirements.  It  is  produced  by  a  systems 
engineering  process  called  synthesis,  and  the  physical  architecture  it  represents  reflects  a  ‘top-down’ 
focus  on  synthesizing  these  operational  requirements.  Accordingly,  all  elements  constituting  that  e- 
bom  must  be  traceable  to— meaning  they  are  verifiable  solutions  to— at  least  one  of  these  require¬ 
ments.  Thus  every  particular  F-22  must  vertically  instantiate  the  structure  represented  by  the  F-22  e- 
bom;  if  it  doesn’t,  it  is  defective— it  is  not  a  valid  material  realization  of  that  axis  of  the  functional 
architecture.21  Should  it  be  flown  in  that  condition,  it  likely  would  not  be  capable  of  executing  its 
mission  with  the  requisite  degrees  of  performance  and  effectiveness. 


21  Lockheed  won’t  get  paid  if  it  doesn’t  either.  The  customer  pays  based  on  acceptable  integration  and  flight  test  results, 
and  thus  pays  indirectly  off  the  e-bom. 
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I  Sustainment  Configurations  and  L-Boms 

The  l-bom  for  a  product  system  represents  its  abstract  infrastructural  architecture.  This  architecture 
defines  an  instrumentality  for  realizing  the  logistic  axis  of  the  functional  architecture  for  the  product 
system  and  its  attendant  reliability  and  supportability  requirements.  Like  an  e-bom,  an  l-bom  is  also 
a  product  of  the  synthesis  process,  and  the  physical  architecture  it  represents  reflects  a  concomitant 
‘top-down’  focus  on  synthesizing  these  integral  logistic  requirements.  Accordingly,  all  elements 
constituting  an  l-bom  must  be  traceable  to  at  least  one  of  these  requirements,  and  every  deployed 
product  must  vertically  instantiate  the  structure  represented  by  its  l-bom.  If  fails  to  do  so,  it  is  defi¬ 
cient—  it  is  not  a  valid  material  realization  of  that  axis  of  the  functional  architecture.  Should  it  be 
used  in  that  condition,  it  likely  could  not  be  maintained  in  the  necessary  state  of  readiness  to  exe¬ 
cute  its  mission  with  the  requisite  degree  of  reliability. 

I  Constructive  Configurations  and  M-Boms 

An  m-bom  for  a  product  system  represents  a  specific  realization  architecture.  This  architecture  is  the 
structural  complement  of  a  specific  and  qualified  production  process  architecture  and  its  attendant 
cost,  schedule,  and  quality  requirements.  Both  this  process  and  its  correlate  m-bom  are  produced  by 
a  process  typically  called  manufacturing  engineering,  and  the  specific  structures  they  represent  reflect  a 
‘bottom-up’  synthesis  of  realization  requirements  required  to  actually  implement  the  abstract  phys¬ 
ical  architectures  represented  by  the  e-bom  and  l-bom  for  a  given  product  system.  Accordingly,  all 
m-bom  elements  must  be  traceable  to  at  least  one  e-bom  or  l-bom  element,  and  be  traceable  to 
requirements  reflecting  producibility,  availability,  socio-economic,  and  regulatory  constraints.  Thus 
every  particular  L-22  must  vertically  instantiate  the  structure  represented  by  the  L-22  m-bom;  If  it 
doesn’t,  it  is  invalid— it  was  not  verifiably  produced  in  accordance  with  a  qualified  production  pro¬ 
cess.  Should  it  be  accepted  in  that  condition,  it  may  not  be  possible  to  validate  its  traceability  to  its 
specified  abstract  physical  architectures,  and,  therefore,  to  its  functional  architecture,  rendering 
both  its  requisite  operational  status  and  logistical  qualifications  indeterminate. 

I  Derivative  Configurations 

The  configurations  described  above  comprise  actual  matters  of  structural  fact  correlate  to  a  specific 
processual  architecture— albeit  diverse  and  in  some  cases  only  contingently  or  periodically  oper¬ 
ant— and,  consequently,  their  respective  boms  are  intended  to  vertically  represent  those  particular 
structures.  Together  with  a  few  others  we  did  not  enumerate  here,  these  foundational  or  genitive 
configurations  collectively  delineate  the  class  of  structures  connected  with  creating,  using,  and  sus¬ 
taining  complex  technical  systems. 

A  second  class  of  configurations  also  exists,  over  and  above  genitive  configurations.  Created  from 
and  supervening  on  these,  derivative  configurations  comprise  analytic  matters  of  structural  fact  keyed 
to  specific  and  purely  intentional  operations  involved  in  creating,  using,  and  sustaining  complex  sys¬ 
tems.  Developed  to  facilitate  the  execution  of  these  processes  by  selectively  abstracting  from  the 
structures  of  other  configurations,  derivative  configurations  are  also  associated  with  specific  repre¬ 
sentational  constructs  specifically  designed  to  convey  their  particular  analytic  structures.  Compris¬ 
ing  redactions  of  other  structural  configurations,  derivatives  are  idealizations,  and  unlike  the 
representations  of  genitive  configurations,  their  representations  are  views. 

The  most  illustrative  examples  of  derivative  configurations  are  those  used  in  resource  and  pro¬ 
duction  planning,  scheduling,  and  cost  accounting  operations.  Created  by  abstracting  from  nominal 
and  constructive  configurations,  these  configurations  are  represented  by  various  special-purpose 
“pseudo”  boms,  such  as  “modular,”  “phantom,”,  and  “flattened”  or  “matrix”  boms.22  Logistical  ana¬ 
logs  of  these  exist  as  well,  comprising  redactions  of  nominal  and  sustainment  configurations.  Being 
artifacts  of  analysis  explicitly  designed  to  facilitate  subsidiary  intentional  processes,  derivative  con¬ 
figurations  of  course  differ  substantially  from  the  actual  matters  of  structural  fact  from  which  they 


22  Matrix  boms  for  instance  are  used  to  compute  requirements  for  components  that  are  common  elements  of  several 
similar  products  or  product  families;  the  underlying  configuration  represented  by  these  contains  only  those  elements 
with  two  or  more  “parents”— so  called  “multiple  where-used”  and  “make  multiple  from”  elements.  The  apics  dictio¬ 
nary  [2]  contains  definitions  and  brief  descriptions  of  these  and  other  similar  structures 
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are  abstracted.  As  we  are  primarily  concerned  with  divergences  among  the  actual  structural  facts 
themselves— major  factors  in  cost,  lead  time,  and  error  rate  attributes  of  product  realization  and 
representation  processes— derivative  configurations  and  their  attendant  representations  are  only  of 
peripheral  of  interest  to  us  here. 

3 . 1 . 1 . 2  Representative  Structure  Divergences 

As  we  stated  above,  every  particular  product  system  will  necessarily  instantiate  several  genitive 
structural  configurations,  specifically  including  a  nominal,  sustainment,  and  constructive  configu¬ 
ration.  And,  each  of  these  configurations  will  inevitably  differ  from  the  others  and  so,  accordingly, 
will  the  e-bom,  m-bom,  and  l-bom  respectively  representing  them.  In  light  of  the  above  characteriza¬ 
tions,  neither  the  fact  these  configurations  differ  nor  the  fact  a  particular  system  necessarily  exem¬ 
plifies  them  all  should  come  as  much  of  a  surprise.  Each  of  these  configurations  is  a  synthesis  of  a 
specific  processual  architecture  and  set  of  requirements— all  of  which  must  be  satisfied  by  a  given 
product  if  it  is  to  attain  the  requisite  degrees  of  performance,  effectiveness,  reliability,  and  validity. 

Divergences  between  two  distinct  genitive  configurations  of  a  particular  complex  product  sys¬ 
tem— for  instance  its  nominal  and  constructive  configurations— exhibit  definite  patterns,  although 
the  individual  intricacy  and  scale  of  each  individual  configuration  can  make  it  difficult  to  discern 
them.  Internal  variability,  contingency,  and  changes  to  an  individual  configuration  over  time  can 
also  obscure  divergences  between  that  configuration  and  its  counterparts.  But  while  the  multi-fac¬ 
eted  phenomenon  of  conditionality  is  a  hallmark  characteristic  of  complex  technical  product  sys¬ 
tems,  especially  within  nominal  and  effective  configurations,  it  is  neither  the  genesis  of  nor  a  basis 
for  explicating  divergence  between  pairs  of  these  configurations.23 

Pair-wise  divergences  between  genitive  configurations  are  positional  optimization  contrasts— they  are 
products  of  deliberate  efforts  to  optimize  the  relationships  that  artifacts  stand  in  to  the  processes  that 
define,  create,  sustain,  use,  and  terminate  them,  governed  by  formal  distinctions  between  these 
relations  themselves.  Thus  the  inter-configuration  divergences  of  interest  to  us  here  are  not  only 
inevitable:  they  are,  in  fact,  signatures  of  design  expertise. 

I  Articulation 

An  atomic  element  in  one  product  structure  configuration  can  frequently  be  a  complex  or  compos¬ 
ite  element  in  another.  We  call  this  form  of  divergence  articulation,  and  it  is  a  common  cause  of  dif¬ 
ferences  between  boms.  For  instance,  the  left  and  right  wing  spars  of  the  f-i8  are  syntheses  of 
certain  aerodynamic  load-bearing  and  rigidity  requirements,  are  consequently  defined  as  atomic 
parts  in  the  nominal  air  vehicle  configuration,  and  are  therefore  represented  as  such  by  the  f-i8 
e-bom. 

However,  each  of  these  spars  are  actually  constructed  by  first  machining  and  then  welding  several 
component  parts  together.  That  is,  it  is  economically  unfeasible  to  procure  the  required  size  of  alu¬ 
minum  bar  that  is  also  free  of  internal  voids.  Moreover,  it  is  a  practical  impossibility  to  install  sin¬ 
gle-piece  spars  during  assembly,  as  there  simply  isn’t  enough  maneuvering  room;  the  spars  must  be 
created  by  welding  several  previously  machined  parts  together  after  these  are  installed  ‘in  rig.’  Thus 
each  spar  in  the  constructive  air  vehicle  configuration  is  an  assembly  rather  than  an  atomic  part,  and  it 
is  accordingly  represented  as  a  subassembly  on  the  f-i8  m-bom. 


23  Except  in  the  most  trivial  senses.  Conditionality  within  the  configurations  of  given  product  system  type,  such  as  c-130, 
is  one  genesis  of  divergence  between  all  of  those  configurations  collectively  and  the  configurations  of  the  concrete 
instances  of  that  type— i.e.,  an  individual  c-130.  For  example,  there  is  certainly  nothing  variable  or  contingent  about 
the  forward  and  aft  extensions  (‘plugs’)  in  the  fuselage  of  a  particular  c-130  belonging  to  the  British  Royal  Air  Force, 
nor  about  their  absence  in  one  equipped  for  short  takeoffs  belonging  to  the  U.N.,  and  naturally,  their  respective  “as- 
built”  and  “as-maintained”  configurations  will  differ  substantially.  However,  differences  such  as  these  are  traceable  to 
conditionalities  in  effective,  nominal,  sustainment,  and  constructive  configurations  known  as  model  effectivities.  These 
define  elements  that  are  operant  (“effective”)  within  the  scope  of  a  specific  variant  of  those  configurations,  but 
which  are  inoperant  (“not  effective”)  outside  that  scope.  Hence  any  two  particular  instances  of  these  models  will  of 
course  be  structurally  distinct.  A  major  genesis  of  differences  between  a  particular  c-130h  built  in  1985  and  a  new  c- 
130j  is  versioning— another  variant  of  conditionality— and  these  are  traceable  to  version  effectivities  within  the  config¬ 
urations  of  given  product  system  type. 
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Articulating  an  element  in  one  configuration  into  several  elements  in  another  can  be  done  in  sev¬ 
eral  ways  and  for  a  variety  of  reasons  beyond  those  of  economic  efficiency  and  assembly  con¬ 
straints  in  realization  process  contexts.  That  is,  articulation  divergences  are  not  limited  to  nominal/ 
constructive  configuration  pairs  and  hence  are  not  limited  to  e-bom/m-bom  pairs.  Sound  instances 
of  articulation  in  product  structure  definition  contexts  always  constitute  solutions  to  specific  engi¬ 
neering,  materials,  manufacturing,  or  logistical  problems.  They  cannot  be  dismissed  as  bad  practice 
or  mere  artifacts  of  representational  convenience  or  eliminated  by  policy.  Inter-configuration  ele¬ 
ment  articulations  are  necessitated  by  empirical  matters  of  fact  or  by  constraints  deriving  from  one 
or  more  requirements. 

I  Factoring 

Two  or  more  separate  and  diverse  elements  in  a  given  product  structure  configuration  can  fre¬ 
quently  be  multiplexed  realizations  of  a  single  element  in  another.  We  call  this  form  of  divergence 
factoring ,  and  it  is  another  common  cause  of  differences  between  boms. 

Some  parts  of  complex  artifacts  inevitably  have  one  or  more  complex  and  difficult  to  produce 
features,  such  as  5 -axis  surfaces,  long  holes  with  small  diameters  and  tight  perpendicularity  toler¬ 
ances,  and  helical  gear  teeth,  to  name  a  few.  Manufacturing  engineers  commonly  factor  these  into 
what  are  sometimes  called  phantom  parts— the  motive  being  efficiency  and  uniformity.  These  are 
gained  by  producing  the  feature  once  on  the  phantom  part,  subsequently  splitting  or  dividing  the 
phantom  to  derive  the  desired  end  products.  The  geometric  forms  of  these  kinds  of  phantom  parts 
are  determined  almost  entirely  by  the  geometry  of  the  feature  to  be  produced,  and  their  spatial 
extents  are  determined  by  the  types  and  number  of  actual  parts  the  phantom  is  designed  to  yield. 

For  example,  helical  gears  in  transmissions  are  syntheses  of  mechanical  power  propagation 
requirements,  are  consequently  defined  as  individual  atomic  parts  in  a  nominal  transmission  con¬ 
figuration,  and  are  therefore  represented  as  such  by  the  relevant  e-bom.  However,  in  the  event  such 
gears  might  share  the  same  tooth  geometry  and  raw  material,  any  competent  manufacturing  engi¬ 
neer  would  factor  these  into  a  single  blank,  thereby  enabling  several  similar  gears  in  the  nominal 
configuration  to  be  produced  from  one  part  in  the  constructive  configuration— that  is,  by  hobbing 
the  blank  and  then  parting  off  the  desired  gears,  Thus  the  separate  individual  gears  would  be  ele¬ 
ments  in  both  the  transmission  e-bom  and  m-bom.  However,  the  m-bom  would  differ  from  the  e-bom, 
in  that  it  would  contain  the  gear  blank  as  an  element,  while  the  e-bom  would  not. 

Like  articulation,  factoring  separate  and  individual  elements  in  one  configuration  into  derivatives 
of  a  single  progenitor  in  another  configuration  can  be  accomplished  in  a  variety  of  ways.  And,  like 
those  originating  from  articulations,  divergences  due  to  factoring  can  exist  between  any  pair  of 
configurations,  and  consequently  between  any  pair  of  boms.  Nor  should  these  differences  be  deni¬ 
grated.  Quite  the  contrary:  factoring  is  a  powerful  efficiency  and  effectiveness  enhancement  tech¬ 
nique-multiplexing  is  a  signature  technique  of  expert  design. 

I  Consolidation 

Two  or  more  separate  and  diverse  elements  in  a  given  product  structure  configuration  can  be  a  sin¬ 
gle  unified  element  in  another.  We  call  this  form  of  divergence  consolidation,  and  it  is  a  third  cause  of 
differences  between  boms.  For  example,  each  of  the  individual  elements  constituting  the  f-i8  avion¬ 
ics  subsystem  are  syntheses  of  various  flight  control  and  vehicle  management  requirements,  are 
consequently  defined  as  subassemblies  and  atomic  parts  in  the  nominal  and  constructive  air  vehicle 
configurations,  and  are  therefore  represented  as  such  by  the  f-i8  e-bom  and  m-bom. 

However,  many  of  these  elements  are  actually  deployed,  inventoried,  and  replaced  as  integral 
units  (“Line  Replaceable  Units”  or  lrus)  rather  than  as  subassemblies  of  individually  accessible 
components.  Electronic  subsystem  elements  such  as  motherboards  or  sealed  electro-optical  inertial 
guidance  packages  are  paradigm  examples  of  lrus.  In  some  cases  lrus  are  designed  to  be  disposed 
of  when  any  of  their  elements  fail  or  preventative  maintenance  schedules  call  for  their  periodic 
replacement;  in  others  they  are  designed  so  they  can  be  disassembled,  repaired  and  refurbished, 
reassembled,  and  subsequently  put  back  into  spares  inventories. 

Consolidating  elements  in  one  configuration  into  a  single  integral  element  in  another  can  be 
effected  in  several  ways.  That  is,  consolidation  divergences  are  not  limited  to  nominal/sustainment 
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configuration  pairs  and  hence  are  not  limited  to  e-bom/l-bom  pairs.  Sound  instances  of  consolida¬ 
tion  in  product  structure  definition  contexts  always  constitute  solutions  to  specific  reliability,  sup- 
portability,  maintainability,  and  logistic  availability  requirements.  And  just  like  articulations,  they 
cannot  be  ignored  or  eliminated  by  policy;  inter-configuration  element  consolidations  are  man¬ 
dated  by  empirical  matters  of  fact  or  by  constraints  deriving  from  one  or  more  requirements. 

3.1.2  Amplitude 

The  structure  multiplicity  need  just  described  is  actually  the  specific  mereological2*  variant  of  a  more 
general  need  which  we  call  representational  amplitude  or  scope.  In  other  words,  the  capability  to 
explicitly  represent  multiple  coincident  and  divergent  genitive  configurations  of  a  given  product 
system  is  one  variation  among  several  constituting  a  major  class  of  amplitude  needs,  and  many  of  the 
shortcomings  of  existing  product  representation  systems  are  symptomatic  of  deficiencies  in  this 
and  other  variants  of  representational  scope.  We  presented  mereological  amplitude  (“structure  mul¬ 
tiplicity”)  as  a  need  distinct  from  and  prior  to  the  other  variants  because  of  its  direct  relationship  to 
the  multiple  bom  problem.  Descriptions  of  the  others,  no  less  crucial  despite  their  indirect  relation¬ 
ships  to  that  particular  problem,  follow  our  remaining  introductory  remarks. 

All  representations,  including  boms,  are  artifacts— they  are  products  of  processes  and  instrumentalities 
for  executing  them.  In  these  two  specific  ways  they  are  indistinguishable  from  all  other  types  of 
artifacts,  and  like  all  the  others,  representations  are  created,  used,  and  sustained  in  order  to  address 
certain  specific  needs.  Despite  this  positional  equivalence  however,  representations  as  a  class  differ 
from  other  classes  of  artifacts  in  one  crucial  respect— they  designate,  describe,  or  depict— in  some 
way  or  another,  they  objectify.  That  is,  representations  are  instrumentalities  of  presentation,  and  it  is 
this  inherently  revelatory  characteristic  that  distinguishes  representations  from  any  other  type  of 
artifact.  The  same  point  conversely  expressed  is  that  representations  exist  to  address  a  unique  class 
of  informatic  needs,  and  the  attributes  constituting  sufficiency  conditions  for  satisfaction  of  those 
specific  sorts  of  needs— i.e.,  representational  performance  and  effectiveness  criteria— are  also  corre¬ 
spondingly  unique. 

Three  signature  characteristics  of  complex  technical  products  and  their  life  cycles  are  complexity, 
variation,  and  novelty.  Each  of  these  exemplifies  many  different  forms.  For  example,  external  or 
extrinsic  complexity  is  scale.  Internal  or  intrinsic  complexity  is  intricacy.  Processual  or  ontogenetic 
complexity  is  extended  interdependence.  Extrinsic  variation  is  heterogeneity.  Intrinsic  variation  is  contin¬ 
gency.  Processual  variation  is  change.  Extrinsic  novelty  is  instatement  or  rescission.  Intrinsic  novelty  is 
consolidation,  factorization,  or  separation.  Processual  novelty  is  innovation.  Thus  extreme  multi¬ 
dimensional  diversity  over  comparatively  long  life  cycles  is  a  hallmark  characteristic  of  complex 
product  systems.  Commensurate  representational  amplitude— the  capability  to  coherently  encompass 
the  full  spectrum  of  these  diversities  across  entire  product  life  cycles— is  a  principal  and  as  yet 
unfulfilled  product  representation  need  that  includes,  but  is  not  limited  to,  the  mereological 
‘dimension’  of  amplitude  previously  described. 

Scope  of  diversity  is  delimitative,  not  quantitative;  it  is  a  classificatory  magnitude  rather  than  a 
numeric  one.  Determining  the  sufficiency  conditions  for  satisfaction  of  this  need  is  consequently  a 
taxonomic  rather  than  a  mathematical  task.  That  is,  stipulating  that  this  need  consists  representations 
of  42  types  of  entities  is  meaningless;  one  must  identify  which  types  constitute  the  requisite  repre¬ 
sentational  scope— although  one  may  of  course  count  them  after  they  have  been  identified  if  one 
wishes  to.  Note  that  in  the  interest  of  brevity  the  listing  that  follows  consists  in  taxonomically 
related  groups  of  types  delimiting  the  requisite  dimensions  of  amplitude,  instead  of  particular  types 
constituting  those  groups,  or  ‘locations’  on  these  dimensions. 

I  Ontogenetic  Amplitude  —Representation  of  Processes  and  Other  Occurrents 

All  product  systems  are  both  directly  and  indirectly  correlated  with  processes  in  a  myriad  of  spe¬ 
cific  ways.  For  example,  most  products  instrumentalize  (i.e.,  materially  enable)  the  execution  of 
processes;  some  directly  execute  them.  The  F-22  and  the  interception  process  is  an  example  of  the 
former;  a  database  management  system  and  data  storage  and  retrieval  processes  is  an  example  of  the 

24  Centered  on  relations  of  part  and  whole— i.e.,  configuration  or  structure  in  the  assembly/ component  relation  sense. 
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latter.  All  artifacts  are  outputs  of  intentionally  directed  realization  processes;  many  are  inputs  to 
these  as  well.  Particular  configurations  of  a  product  are  keyed  to  specific  application  processes  or 
realization  process  phases  as  we  previously  described  in  some  detail.  Finally,  particular  versions  of 
product  configurations  are  correlated  with  changes  in  application  or  realization  processes.  Applica¬ 
tion  process  changes  are  consequents  of  changes  in  instrumental  needs  or  requirements  resulting 
from  shifts  in  user  purposes.  Realization  process  changes  are  made  to  correct  flaws,  mitigate  defi¬ 
ciencies,  exploit  new  technologies,  and  typically  result  in  enhanced  product  performance  and 
effectiveness. 

Moreover,  many  ‘products’  of  so-called  service  enterprises  or  service  organizations  within  enter¬ 
prises  are  processes,  not  products  in  the  sense  we  have  been  using  that  term  here.  The  formally  quali¬ 
fied  analysis,  production,  and  assurance  processes  used  by  aerospace  and  defense  enterprises  and 
their  commercial  peers  to  create,  validate,  and  support  their  products  are  examples  of  these,  as  are 
most  of  the  ‘products’  of  medical,  financial,  and  governmental  institutions.25  All  such  processes  are 
themselves  artifacts,  designed,  developed  and  sustained  via  sophisticated  realization  processes  like 
any  other  artifact;  they  also  encompass  effective,  nominal,  constructive,  and  sustainment  configu¬ 
rations,  and  they  are  frequently  comparable  in  complexity,  variation,  and  novelty  to  the  most  com¬ 
plicated  technical  product  systems. 

The  fundamental  distinction  between  enduring  objects  that  exemplify  persistent  qualities  on  the 
one  hand  and  intrinsically  dynamic  entities  such  as  processes  and  events  on  the  other  is  utterly 
entrenched  in  our  everyday  conception  of  the  world.  Commonly  called  the  continuant/ occurrent  dis¬ 
tinction  in  philosophical  circles,  it  is  reflected  in  the  grammatical  forms  of  all  of  our  natural  lan¬ 
guages  by  the  distinction  between  noun  and  verb,  and  it  is  instantiated  in  various  forms  by  almost 
all  of  the  formal  languages  and  systems  we  use  to  model  the  world  and  our  representations  of  it. 
Furthermore,  almost  all  of  our  languages  and  formal  systems  also  exemplify  a  pervasive  although 
implicit  bias  towards  continuants,  and  nowhere  is  this  more  evident  than  in  existing  product  repre¬ 
sentation  systems,  which  without  exception  utterly  fail  to  explicitly  represent  occurrents  at  all— let 
alone  represent  their  structures— except  in  trivial  textual  form.  Continuants  are  ‘objects;’  thus  they 
are  easily  objectified  for  these  purposes.  However,  occurrents  are  not  ‘objects;’  one  simply  doesn’t 
put  one’s  hands  on  processes,  nor  easily  determine  their  characteristics,  except  obliquely  in  terms 
of  their  outputs.  Accordingly  it  takes  a  certain  turn  of  mind  to  seriously  undertake  to  explicitly  repre¬ 
sent  them  as  entities  on  par  with  continuants,  instead  of  implicitly  and  indirectly  representing  them 
via  continuant  surrogates— for  example,  as  lines  of  text  in  documents. 

The  crucial  need  for  representational  parity  across  both  sides  of  the  continuant/occurrent  divide 
should  be  clear,  given  the  numerous  and  multi-faceted  relationships  between  them.  The  imperative 
need  for  ‘product’  representation  systems  to  explicitly  represent  occurrents  directly  should  be 
equally  clear,  in  light  of  their  status  as  artifacts  or  ‘products’  themselves. 

I  Nomological  Amplitude  —Representation  of  Needs,  Requirements,  and  Metrics 

All  artifacts  are  created  to  instrumentalize  the  accomplishment  of  certain  purposes.  Purposes  are 
possible  states  that  one  or  more  agencies  desire  to  be  actual;  thus  accomplishment  is  actualization— 
an  outcome  of  effective  actions  or  processes.  “Effective”  means  that  the  result  state  is  satisfactorily  con¬ 
gruent  to  the  desired  state.  “Satisfactorily  congruent”  means  that  some  requisite  degree  or  measure  of 
effectiveness  has  been  defined  as  a  criterion  of  success. 

Conditions  that  impede  or  block  the  execution  of  effective  actions  or  processes  are  called  needs— 
capability  voids  with  respect  to  actualizations  of  desiderative  states.  Instrumental  or  intrinsic  needs 
are  capability  voids  respecting  mechanisms  of  actions  or  processes— they  are  exigencies  of  artifacts. 
Thus  satisfaction  of  these  needs  is  instrumentalization— an  outcome  of  effective  artifact  (‘product’)  real¬ 
ization.  “Effective”  in  this  context  means  that  the  resulting  artifact  is  suitably  functional  for  the  action 
or  process.  “Suitably  functional”  means  that  one  or  more  measures  of  performance  have  been  defined 
as  criteria  for  fitness  of  application  or  use,  and  artifacts  instantiating  these  are  called  solutions. 


25  More  precisely,  the  ‘products’  are  process  performances ,  not  the  processes  themselves.  Nevertheless,  the  point  that 
[performances  of]  processes  are  not  products  in  the  sense  we  have  been  using  that  term  is  valid  with  or  without  the 
additional  precision. 
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Accomplishing  the  kinds  of  purposes  relevant  to  our  discussion  here  always  necessitates  success¬ 
ful  execution  of  complex  operations  comprising  many  distinct  integrated  processes;  they  cannot  be 
immediately  and  directly  achieved  by  atomic  actions.  That  is,  actualizations  of  these  kinds  of  desid- 
erative  states  invariably  depend  upon  coordinated  actualizations  of  antecedent  states.  The  effective¬ 
ness  of  such  operations  is,  therefore,  an  essentially  distributive  feature  of  the  effectiveness 
characteristics  of  their  constituent  processes  and  actions.  Consequently,  achieving  satisfactory  con¬ 
gruences  between  the  final  states  actualized  by  these  operations  and  the  desiderative  states  their 
correlated  purposes  stipulate  mandates  subdivision  of  their  measures  of  effectiveness  and  subse¬ 
quent  assignment  to  their  constituent  processes  and  actions.  This  subdivision  and  assignment  is 
called  allocation. 

Conditions  that  impede  or  block  the  execution  of  actions  or  processes  constituting  complex 
operations  are  called  requirements— capability  voids  pertaining  to  actualizations  of  antecedent  states  of 
desiderative  states.  Instrumental  requirements  are  capability  voids  respecting  constituent  actions  or 
processes  of  complex  operations— they  are  entailments  of  instrumental  needs  or  other  instrumental 
requirements  and  thus  are  exigencies  of  artifact  elements.  Fulfillment  of  requirements  is  synthesis— an 
outcome  of  effective  artifact  decomposition ,  element  realization,  and  integration.  The  performance  char¬ 
acteristics  of  such  artifacts  are,  therefore,  functionally  dependent  upon  the  performance  character¬ 
istics  and  integrity  of  their  elements  and  are  aggregates  of  these.  Consequently,  achieving  requisite 
levels  of  instrumental  performance  necessitates  systematic  allocations  of  those  measures  to  artifact 
elements. 

Needs,  requirements,  operational  measures  of  effectiveness,  functional  performance  measures, 
and  the  multi-dimensional  networks  of  dependence,  allocation,  and  containment  relationships 
among  these  collectively  constitute  functional  and  realization  architectures  of  product  or  process  sys¬ 
tems.  These  architectures  are  the  ultimate  determinants  of  all  structural  configurations  and  systemic 
characteristics.  They  are  the  rationale  for  why  artifacts  are  they  way  they  are;  they  are  the  ultimate 
analytic  factors  to  which  ah  synthetic  facts  are  traceable;  they  are  their  genesis  and  their  final  rea¬ 
sons.  Nevertheless,  existing  product  representation  systems  completely  fail  to  represent  them,  as 
these  architectures  and  their  elements  are  altogether  beyond  their  representational  capabilities. 
And,  nothing  demonstrates  the  gravity  of  this  unfulfilled  representational  need  more  effectively 
than  the  pervasive  and  persistent  problems  with  the  engineering  change  process— especially  its 
impact  analysis  and  propagation  subprocesses. 
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3.2  Product  Representation  Requirements 

We  have  divided  the  requirements  antecedent  to  the  product  representation  needs  outlined  in  para¬ 
graph  3.1  into  three  distinct  groups— metastructures,  functional  capabilities ,  and  superordinate  enterprise 
operating  system  requirements.  The  first  two  groups  are  presented  below  in  paragraphs  3.2.1  through 
3.2.6;  the  latter  are  partially  sketched  in  Section  4,  Results  Part  II. 

We  limited  our  analysis  to  those  requirements  which  are  critical,  formal,  and  immediately  ante¬ 
cedent  to  the  identified  needs,  thereby  excluding  several  classes  of  operational  requirements  from 
our  analysis.  Specifically,  we  did  not  derive  or  develop  characterizations  of  performance,  utiliza¬ 
tion,  and  life-cycle  “illity”  requirements  that  would  naturally  follow  from  an  empirical  analysis, 
focused  on  specifying  sufficiency  conditions  for  synthesis  and  implementation.  Again,  our  aim  was 
to  fill  a  requirements  definition  void  by  identifying  core  formal  requirements  for  all  possible  solutions 
to  these  particular  product  representation  needs,  independently  of  any  requisite  technical,  eco¬ 
nomic,  or  strategic  considerations.  Nevertheless,  a  complete  and  effective  product  representation 
solution  will  have  to  satisfy  all  requirements  deriving  from  these  and  other  related  needs,  not  just 
those  presented  here.26  However,  any  viable  information  system  element  of  such  a  solution  will 
necessarily  satisfy  the  first  two  groups  of  requirements,  and  any  total  solution  will  necessarily  sat¬ 
isfy  all  three. 

3.2.1  Metastructure 

The  17  specific  relation  types  depicted  in  Table  1  below  collectively  constitute  the  necessary  infor- 
matic  metastructures  required  to  satisfy  the  product  representation  needs  previously  outlined  in 
paragraph  3.1.  That  is,  any  information  system  solution  to  those  needs  must  explicitly  implement 
representations  of  these  17  structures  and  provide  facilities  for  creating,  modifying  and  querying 
instances  of  them. 

The  metastructures  are  divided  into  two  distinct  groups.  Core  metastructures  comprise  the  essen¬ 
tial  elements  required  to  represent  the  basic  mereological  structure  and  morphology  of  any  entity  at 
all.  Adjunct  metastructures  encompass  three  subsidiary  groups.  Intrinsic  adjuncts  constitute  those 
required  to  explicitly  represent  systematic  variability  among  the  members  of  a  given  entity  type. 
Extrinsic  adjunct  metastructures  constitute  those  required  to  explicitly  represent  relations  between 
elements  of  one  structural  configuration  and  its  counterparts  in  others,  and  intertypic  adjuncts  con¬ 
stitute  those  required  to  explicitly  represent  relationships  between  the  taxonomically  distinct 
entity  types  in  a  complete  product  representation. 

We  do  not  address  schematic  or  metaschematic  product  representation  content  requirements 
over  and  above  those  pertaining  to  the  specific  structures  in  Table  1.  That  is,  we  are  not  concerned 
with,  nor  do  we  specify,  any  entity  types  or  attributes  of  entity  types  excepting  those  which  are 
directly  entailed  by  the  definitions  of  the  above  relation  types.  This  is  not  to  say  that  such  charac¬ 
teristics  are  unimportant  to  a  product  representation  system:  they  are  very  important  indeed.  How¬ 
ever,  our  focus  here  is  on  previously  unidentified  or  incompletely  articulated  requirements  deriving 
from  the  needs  identified  above,  not  on  recapitulating  those  which  have  already  been  identified  by 
others.27 


26  Product  representation  visibility  requirements  deriving  from  certain  stakeholder- specific  needs  are  an  illustrative  exam¬ 
ple.  Customers  and  Suppliers  (and  in  some  cases,  certain  regulatory  agencies),  need  access  to  product  representations, 
albeit  for  different  purposes.  Many  so-called  ‘customer  relationship  management’  and  ‘supply  chain  integration’  prob¬ 
lems  are  symptomatic  of  the  narrow  focus  and  limited  capabilities  of  existing  product  data  management  systems  to  sat¬ 
isfy  these  requirements,  especially  those  which  are  unique  to  complex  manufacturing  environments  such  as  aerospace 
and  defense.  Both  end-user  visualization  and  programmatic  access  requirements  also  fall  under  this  group;  they  are 
actually  agency  type-specific  product  representation  visibility  requirements  as  well.  These  were  deliberately  excluded 
from  our  analysis,  as  they  are  neither  formal  nor  directly  antecedent  of  the  identified  needs.  Nevertheless,  they  do 
constitute  a  necessary  set  of  satisfaction  conditions  for  a  complete  and  effective  product  representation  solution. 

27  For  example,  a  massive  amount  of  work  to  define  the  entity  type  product  definition,  its  attributes,  variants,  and  a 
host  of  related  entity  types,  has  already  been  produced  by  efforts  such  as  step,  as  we  mentioned  before.  Another 
example  is  the  entity  type  document,  a  critical  relatum  of  several  relation  types  we  define  here.  The  sgml  DocBook 
dtd  (Document  Type  Definition)  [23],  is  a  monumental  representation  of  a  ‘tech  pub’  variant  of  that  entity  type.  Our 
objective  is  to  fill  a  requirements  definition  void,  not  to  restate  the  results  of  these  and  many  other  similar  efforts. 
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TYPE 

RELATION  OF 

RELATION  BETWEEN*-* 

EXAMPLES 

l1  II 

COMPOSITION 

(  Containment 

Entities<-*Elements 

SYSTEMSOSUBSYSTEMS;  ASSEMBLIES*-*COMPONENTS 

2  | 

CONSTITUTION 

|  Materiality 

|  EntitiesoMaterials 

partsoraw  materials;  compounds*-*chem  elmts 

Ui 

o 

1  3  1 1 

INHERENCE 

Characterization 

|  Entities<-*Attributes 

PARTS<-*FEATURES;  SYSTEMS*~*PERFORMANCE  CHARS 

V 

Ml 

QUALIFICATION 

Conditionality 

Relations*-*Antecedents 

NEEDS*~*REQMTS;  PROCSOlNPUTS;  COMPSTNS*-*EFFIES 

1  s  II 

QUANTIFICATION 

Multeity 

RelataoQuantities 

TPMSOTPM  VALUES;  WHERE-USED  QUANTITIES 

6 1 

EQUIVALENCE 

Substitutionality 

Relata<-*Substituends 

MIL-P-18177  TYPE  Gl0*-*LP-509  CLASS  II  GRADE  A 

U 

ZJ 

ALTERNATION 

Optionality 

RelataO  Alternatives 

F-16  AVIONICS*"*COUNTRY-SPECIFIC  PACKAGES 

!/> 

Z 

0 £ 

«JL 

VARIATION 

Diversity 

Baselines*-*  Variants 

jsf*-*(af  variant, stol  variant) 

h- 

Z 

9 

ORDER 

|  Positionality 

Entities*-*Positions 

ASSEMBLY  ORDER;  SERVICE  PRECEDENCE 

10  | 

TRANSFORMATION 

Development 

Entities*-*States 

C-130H*-*C-130j;  LINUX  KERNEL  V2.0.3*-»V2.0.4 

u 

z 

y 

ill! 

ARTICULATION 

Separation 

NOZZLE  ASSEMBLY*-*<THROAT, CHAMBER, EXIT  CONE> 

D 

Q 

i 

121 

FACTORIZATION 

|  Abstraction 

EntitiesoRealizations 

(GEAR1  ,GEARj,GEARn)*-*GEAR  BLANK 

“L 

13J 

CONSOLIDATION 

Integration 

(chips, boards, housing)*-*avionics  LRU 

•  t 

ill 

INVOLVEMENT 

|  Participation 

Continuants*-*Occurrents 

PRODUCTS*~*FUNCTIONS;  ATTRIBUTES*-*TEST  PROCS 

vy 

Q. 

>- 

ill 

CAPACITATION 

Provisionment 

lnvolvements*-*Tools;  Agencies  | 

f-18e/f  assembly*-*{fixtures;  jigs;  assemblers} 

s 

h- 

161 

REPRESENTATION 

Objectification 

Entities*-*Representations 

prdcts*-*{eng  dwgs.data};  procs*-*{tech  mnls.code} 

z 

!Zj 

DESIGNATION 

Nominalization 

Entities*-*Designators 

PARTS<H>PART  NUMBERS;  AIRCRAFT*-*TAIL  NUMBERS 

Table  1.  Product  Representation  Metastructure  Relation  Types 


Our  descriptions  of  requirements  for  the  core  metastructures  is  extremely  detailed  and  is  pre¬ 
sented  in  paragraph  3.2.2.  Our  presentation  of  requirements  for  the  adjunct  metastructures  summa¬ 
rizes  their  formal  definitions  as  those  stood  at  the  end  of  the  mereos  program.  To  support  our  post- 
mereos  program  enterprise  engineering  activities,  we  have  subsequently  launched  an  effort  under 
our  own  auspices  to  develop  new  and  much  more  comprehensive  characterizations  of  the  adjunct 
metastructures.  We  will  make  the  new  requirements  specifications  publicly  available  when  this 
effort  is  completed. 

Finally,  we  should  stress  that  our  focus  is  on  requirements,  not  implementation  issues  such  as  the 
choice  of  one  database  management  system,  geometric  modeling  system,  or  programming  language 
over  another.  While  some  of  these  may  be  better  suited  than  others  to  implementing  the  formal 
requirements  we  define  here,  our  purpose  is  to  articulate  w hat  these  requirements  are,  not  how  they 
might  be  effectively  synthesized  into  an  implementation.  In  a  word,  our  objective  is  to  define  the 
formal  structures  required  to  address  the  previously  presented  informatic  needs. 
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3.2. 1.1  SOA  Syntax  and  Notational  Conventions 

The  metastructures  in  the  above  table  could  be  rendered  in  a  variety  of  ways  for  our  formal  descrip¬ 
tive  purposes.  We  have  chosen  to  present  them  using  state-of- affairs  (soa)  syntax  and  semantics,  as 
these  are  satisfactory  for  the  task  at  hand,  and  the  notation  is  easily  assimilated,  interpreted  and 
implementationally  neutral. 

There  are  two  variants  of  soa— plural  and  monadic.  A  plural  soa  is  a  structure  of  the  form: 

<R,<*i . xn)) 

where  R  designates  a  relation  type,  (x1v..,xn)  designates  a  member  of  relation  type  R,  and  Xj  designates 
some  entity  standing  in  the  ith  place  of  relation  R.  A  monadic  soa  is  a  structure  of  the  form: 

<*,<x» 

where  b  designates  a  property  type,  and  x  designates  some  entity  instantiating  that  property.28  Exam¬ 
ples  of  the  plural  and  monadic  variants  are: 

(Loves, (John, Mary))  or  (Intelligent, (Mary)); 

(+,( 2,2,4))  or  (Prime, (3));  and, 

(Composition, (F-225005,Enginepw042)). 

Note  we  use  the  generic  term  extant  to  designate  either  the  n-tuple  or  7-tuple  in  soas;  thus 
(F-225005,EnginepW042)  in  the  soa  (Composition, (F-225005,EnginepW042))  or  (Mary)  in  the  soa  (Intelligent, (Mary)) 
are  called  the  “extants”  of  those  soas.  Two  or  more  soas  whose  extants  encompass  at  least  one  ele¬ 
ment  in  common  are  called  co-incident;  those  whose  extants  encompass  exactly  the  same  elements 
are  called  co-extensive. 

I  Soa  Schemes 

Since  we  are  using  soas  to  describe  product  representation  metastructures,  definitions  will  be  ren¬ 
dered  in  terms  of  soa  schemes  rather  than  soa  instances,  the  latter  being  used  only  as  examples.  An 
soa  scheme  is  a  structure  of  the  form: 

(R, (ATTRIBUTE^..., ATTRIBUTEn  ))  07  (b, (EXEMPLAR)) 

where  again  R  designates  a  relation  type  and  ATTRiBUTEj  designates  an  entity  type  whose  instances  stand 
in  the  ith  place  of  relation  R;  or  where  and  b  designates  a  property  type,  and  exemplar  designates  some 
entity  type  whose  instances  instantiate  that  property.  An  example  of  such  a  scheme  for  the  composi¬ 
tion  relation  is: 

(Composition, (Complex, Element)). 

Soa  schemes  as  we  will  be  rendering  them  are  really  syntactical  shortcuts  for  a  much  more  com¬ 
plex  form  of  soa  whose  relation  is  delimitation,  and  whose  extension  comprises  types  necessary  to 
define  a  class  of  soas,  such  as  the  relation  type,  its  attributes,  relevant  qualification/quantification 
conditions,  possible  variants,  and  context  element  types.  Where  applicable  these  other  elements 
are  defined  textually  rather  than  in  soa  syntax.29 

We  will  use  the  generic  term  extension  to  designate  the  schematic  counterpart  of  an  soa  extant; 
thus  (Complex, Element)  in  the  scheme  (Composition, (Complex, Element))  or  (IntentionalBeing)  in  the  scheme 
(Intelligent, (Intentional  Being))  are  called  the  “extensions”  of  those  soa  schemes.  Again,  this  is  really  a 
notational  shortcut  for  { (xi,...,Xj)1,...,(xk,...,xw)n }  or  { (x),...,(y),...,(z) }  —that  is,  the  set  of  all  n-tuples  or 
set  of  all  7-tuples  constituting  the  extensions  of  a  given  type  R  or  d-  Two  or  more  soa  schemes 
whose  extensions  encompass  at  least  one  entity  type  (attribute  or  exemplar)  in  common  are  called 
congruent;  those  whose  extants  encompass  exactly  the  same  types  are  called  conspecific. 


28  In  lisp  speak  an  soa  is  a  list;  in  relational  database  speak  an  soa  extant  (x1v..,xn)  is  called  a  row  or  tuple;  etc. 

29  There  are  really  two  reasons  why  we  have  employed  this  delimitation  shorthand.  First  of  all,  it  is  much  less  distract¬ 
ing  than  a  complete  presentation  would  be.  Secondly,  it  is  adequate  for  conveying  the  essential  product  representa¬ 
tion  requirements  we  are  concerned  with  presenting  here.  A  complete  delimitation  is  a  very  complex  structure 
indeed— the  drawing  entitled  Architecture  Element  Elements  in  Figure  30  in  Attachment  2  depicts  this  structure. 
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I  Adicity,  Order,  Reflection,  and  Self- Application 

The  extensions  of  soas  and  soa  schemes  can  be  ‘nested’  in  two  fundamental  and  two  derivative 
ways.  First,  an  element  of  the  extant  of  a  plural  soa  can  itself  be  a  polyadic  plurality  or  n-tuple: 

(Loves, (Mary, (Frank, Joe, Bill, John, Bob))) 

Second,  an  element  of  the  extant  of  either  plural  or  monadic  soas  can  itself  be  an  soa: 

(Designation, (“John’s  Favorite  SOA”, (Loves, (John, Mary))))  or 
(True, ((+,(2,2,4)))) 

In  the  above  examples  the  Designation  and  True  soas  are  border;  the  Loves  and  +  soas  lst-order. 

There  is  a  specific  variant  of  higher-order  soas  called  reflection.  A  reflective  soa  is  a  2nd-order  or 
above  soa  that  contains  an  instance  of  the  same  soa  scheme  as  an  element  in  its  extant.  For  example 

(Designation, (“John’s  Favorite  Designation  SOA”, (Designation, (“John’s  Favorite  SOA”, (Loves, (John, Mary)))))) 

is  reflective  in  that  the  object  of  the  nominal  designator  in  the  top-level  Designation  soa  is  itself  a 
Designation  soa.  Finally,  there  is  a  variant  of  reflection  called  self-application.  A  self- applicative  soa  is  a 
reflective  soa  that  contains  itself  as  an  element  in  its  extant. 

Any  of  these  forms  of  nesting  can  potentially  occur  in  a  single  soa  extant,  subject  to  schematic 
and  empirical  constraints. 

I  Soa  Rank 

Instances  of  soa  schemes  are  classified  in  three  fundamental  ways.  The  first  is  by  their  relations.  The 
second  is  by  their  order  as  defined  in  the  prior  paragraph.  The  third  is  the  metasystematic  ranks  of  the 
entities  in  their  extants.  The  two  ranks  relevant  to  our  purposes  here  are  taxon  and  individual.30 
Consider  the  following  two  examples: 

(Composition, (F-225005,Enginepw042))  and  (Composition, (F-22, Engine)). 

The  elements  constituting  the  extant  of  the  first  Composition  instance  above  clearly  designate  a 
particular  individual  F-22  and  engine,  respectively,  while  those  of  the  second  do  not— they  desig¬ 
nate  the  F-22  and  engine  product  types,  or  taxa.  Thus  the  rank  of  the  first  soa  is  individual,  and  the 
rank  of  the  second  is  taxon. 

The  majority  of  soa  instances  of  rank  taxon  represent  elements  in  the  delimitations  of  the  entity 
types  (i.e.,  attributes)  in  their  extants,  such  as  F-22,  allocation  (the  process)  or  requirement  specifi¬ 
cation  (the  document  type).  For  example,  the  Composition  instance  of  taxon  rank  above  is  defining  a 
mereological  containment  relation  between  members  of  the  product  taxon  F-22  and  members  of 
the  engine  taxon.  Soas  such  as  these  are  the  formal  analogs  of  structures  implemented  by  e-boms, 
m-boms,  and  l-boms,  which  represent  the  structures  of  product  types  as  opposed  to  those  of  particu¬ 
lar  individual  products.  Again,  these  soas  are  syntactical  shortcuts  for  (Delimitation, (...))  soas— in  these 
cases  they  are  elements  of  delimitations  of  entity  rather  than  relation  taxa. 

Soa  instances  of  rank  individual  represent  elements  of  particular  members  of  entity  types.  For 
example,  the  Composition  instance  of  individual  rank  above  is  defining  a  mereological  containment 
relation  between  F-22  tail  #5005  and  Pratt  Sc  Whitney  engine  serial  #042.  These  are  the  formal  ana¬ 
logs  of  structures  implemented  by  serialized  “as-built”  and  “as-maintained”  boms,  which  represent 
particular  structures  of  particular  instances  of  product  types. 

In  some  cases  elements  in  the  extants  of  soas  can  differ  in  metasystematic  rank,  making  ascrip¬ 
tion  of  it  to  the  containing  soa  less  obvious  than  cases  where  the  rank  of  all  extant  elements  are  the 
same.  For  example,  the  ranks  of 

(Designation, (“5005”, theFirstFlightF-22))  and  (Designation, (LMF-22Designator, F-22)) 


30  There  are  four  metasystematic  ranks  or  categories  in  our  own  formal  system:  category,  taxon,  individual,  and  fact. 
Thus  in  principle  the  relata  in  any  soa  instance  or  scheme  could  be  of  any  one  of  these  four  ranks.  However  in  practice 
this  categorial  scope  is  not  necessary  for  multiple  bom  reconciliation.  We  have  not,  accordingly,  imposed  it  as  a  prod¬ 
uct  representation  requirement  here. 
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are  clearly  individual  and  taxon,  respectively;  while  the  rank  of 
(Designation,  (“Raptor”,  F-22)) 

is  not  obvious,  as  “Raptor”  is  a  particular  designator,  but  F-22  is  clearly  a  product  taxon,  not  a  partic¬ 
ular  airplane.  We  will  address  the  question  of  rank  of  such  ‘mixed  rank’  soas  on  a  case-by-case  basis 
where  it  is  important  to  specifying  requirements. 

I  Modal  Soas  and  Contexts 

Any  2nd-order  or  above  soa  modifies  or  modalizes  the  soa  or  soas  in  its  instance,  and  the  plurality  of 
modal  soas  immediately  containing  a  given  soa  as  elements  in  their  extants  collectively  constitute 
the  context  of  that  soa.  Rendering  this  as  an  explicit  soa  itself,  a  context  is  a  structure  of  the  form 

(Context, (ObjectSoA,(ModalSoA1 , . . .  ,ModalSoAn )) 

where  Context  is  a  special  form,  where  ObjectSoA  is  the  target  soa  modalized  by  one  or  more  nth-order 
soas,  and  where  ModalSoAj  is  an  soa  containing  ObjectSoA  as  an  element  of  its  extant.  An  explicitly 
contextualized  soa  is  rendered  using  the  form: 

<[  ].<R.<Xi . xn ))) 

(RW,(Xl . SOAx,...Xn  )) 

<(|)a,<SOAx)} 

where  [  ]  designates  the  context  of  the  target  soa,  (Rw,(x1,...SOAx,...xn))  and  (<|)a,(S0Ax))  designate  the 
[n+1f  -order  modalizing  soas,  and  where  soax  designates  the  nth-order  soa. 

We  will  use  the  term  intension  to  designate  the  schematic  counterpart  of  an  soa  context. 

I  Complementarity 

By  default  all  soas  are  positive;  that  is,  they  represent  affirmations  of  facts.  Thus  the  soa 
(Composition,  <  F-225005 ,  Eng  i  nepw042» 

represents  a  containment  relation  between  a  particular  F-22  and  a  particular  Pratt  &  Whitney 
engine,  asserting  that  engine  serial  number  PW042  is,  in  fact,  a  component  element  of  F-22  tail  num¬ 
ber  5005. 

However,  it  is  sometimes  necessary  to  explicitly  represent  a  negative  fact— that  is,  a  fact  of  opposition. 
The  special  modal  form  called  complementarity— the  modality  of  polarity— together  with  its  two 
variants  thetic  (positive),  denoted  by  the  symbol  and  kenonic  (negative),  denoted  by  the  symbol 
^ ,  is  employed  for  this  purpose.  Thus  the  explicitly  designated  kenonic  soa 

([  ],  (Composition,  <F-225005,  E  ng  i  n  epw042») 

'(?  i<SOAw,)) 

k- 

represents  the  fact  that  engine  serial  number  PW042  is  not  a  component  element  of  F-22  tail  number 
5005. 

Note  that  kenonic  and  uniformly  rank  individual  soas  represent  particular  negations,  and  that 
kenonic  and  uniformly  rank  taxon  soas  represent  specific  delimitative  exclusions. 

I  Identities 

As  we  mentioned  in  our  introductory  remarks,  the  informatic  metastructures  required  to  satisfy  the 
product  representation  needs  we  are  concerned  with  here  are  all  relations  between  entities,  and  we 
are  accordingly  only  concerned  with  defining  requirements  pertaining  to  those  and  their  immedi¬ 
ately  entailed  content  requirements.  Some  of  these  involve  related  entity  types  and  their  attributes, 
and  not  all  entities  are  relations  or  properties.  For  example,  neither  the  product  type  F-22  nor  the 
instance  of  that  type  F-22  tail  #5005  are  relations  between  entities  or  properties  of  them.  While  we 
are  not  concerned  with  enumerating  the  characteristics  of  the  F-22  or  indeed  product  itself,  we  will 
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on  occasion  need  to  specify  requirements  for  entities  which  are  not  relations  or  properties.  Such 
entities  are  rendered  by  instances  of  the  identity  soa  scheme: 

<[  ],  (Identity/))) 

(Designation,  <“x” ,  t  h  e  I  d  e  n  t  i  ty  so  a» 

(Rm,(f, . . .  ,theldentitysoA, . .  .g)) 

■((|)a,(theldentitysoA)) 

(Rw,(s, . . .  ,theldentitysoA, . .  .q)) 

■  etc. 

where  Identity  is  an  extensionless  special  form.  Note  that  soas  containing  x  as  elements  in  their 
extants  actually  contain  the  soa  theldentitysoA — that  is,  “x”  in  our  standard  soa  notation  is  really  a  syn¬ 
tactical  shortcut  for  an  identity  soa  instance,  modalized  by  a  designation  soa  with  “x”  as  its  desig¬ 
nator.31 

I  Particulars 


The  identity  special  form  encompasses  four  specific  variants,  called  “particulars,”  derived  by  vary¬ 
ing  complementarity,  metasystematic  rank,  and  adicity. 


1.  Bare  particular 


2.  Arbitrary  particular 


3.  Null  particular 


4.  Indeterminate  particular 


-  the  thetic  (^)  rank  individual  variant  of  identity.  Instances 
of  this  variant  represent  pure  extensionless  facts  of  positive 
individuality,  connoted  by  the  terms  “this”  or  “these.” 

-  the  thetic  (^)  rank  taxon  variant  of  identity.  Instances  of  this 
variant  represent  pure  extensionless  facts  of  positive  taxicity, 
connoted  by  the  terms  “anything”  or  “any  things.” 

-  the  kenonic  (e^ )  rank  individual  variant  of  identity.  Instances 
of  this  variant  represent  pure  extensionless  facts  of  negation, 
connoted  by  the  terms  “nothing”  or  “no  things.” 

-  the  kenonic  )  rank  taxon  variant  of  identity.  Instances  of 
this  variant  represent  pure  extensionless  facts  of  exclusion, 
connoted  by  the  terms  “something”  or  “some  things.” 


I  Indexicals 


It  is  sometimes  necessary  for  an  element  in  the  extant  of  one  soa  to  explicitly  address  or  ‘point  at’ 
or  ‘virtually  contain’  one  or  more  elements  of  another  soa,  in  situ.  The  indexicalization  special  form32 
is  used  to  accomplish  this,  and  it  is  a  structure  of  the  general  form: 

SourceSoax:  ([  ],(R,  <x-, , . . . ,<lndexicalization,<TargetSoA, ReferentCoordinate)), . . . ,xn ))) 

where  SourceSoax  designates  the  soa  containing  the  indexical  element,  TargetSoa  designates  the  soa 
whose  element  is  being  situationally  referred  to  as  an  extant  element  in  SourceSoax,  and  where  Refer¬ 
entCoordinate  designates  a  target  soA-specific  coordinate,  and  sometimes  an  soa  instance  extant-spe¬ 
cific  configuration  coordinate.  This  coordinate  either  designates  the  ordinal  position  of  the 
referent  element  in  the  target  soa  instance,  or  is  a  unique  or  uniquely  resolvable  nominal  designa¬ 
tion  of  that  element  in  that  position.  Note  that  all  indexicals  are  necessarily  embedded;  that  is,  they 
are  necessarily  extant  elements  of  other  soas.  They  are  at  least  2nd-order,  thus  they  are  also  context 
elements  of  their  target  soas. 


31  From  this  we  can  state  a  refinement  to  our  prior  definitions  of  ist-order  and  2nd-order  soas.  A  lAorder  soa  is  one 
whose  extant  elements  consist  solely  of  identity  soas  or  “terminal  values;”  nominal  designators  being  examples  of 
these.  A  2nd-order  or  above  soa  is  one  containing  at  least  one  P-order  or  above  soa  as  an  extant  element. 

32  Strictly  speaking  indexicalization  is  a  variant  of  the  designation  relation  type  defined  in  paragraph  3. 2. 5. 4.  We  have 
defined  it  here  as  it  will  be  used  extensively  prior  to  that  paragraph. 
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I  Graphics 

Representation  system  metastructures  are  instrinsically  abstract,  intricately  inter-related,  and  corre¬ 
spondingly  difficult  to  communicate.  Over  the  course  of  the  mereos  program,  we  developed  a  series 
of  graphics  to  assist  in  developing  our  conceptualizations  of  these  structures.  Although  there  is  no 
substitute  for  unambiguous  syntax  and  illustrative  examples,  we  have  found  these  visualizations 
helpful  and  thus  have  incorporated  them  into  the  definitions  presented  here.33 


Figure  3.  Metastructures  in  Graphical  Form 


33  A  complete  and  much  larger  version  of  Figure  3  above  is  included  in  Figure  33  in  Attachment  2. 
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I  Symbology 

For  the  sake  of  typographical  brevity  we  will,  on  occasion,  use  certain  symbols  in  conjunction  with 
our  soa  notation,  as  follows: 

:=  assignment  -  attribute  type  delimitation  or  attribute  instance  entity  identification 

=  identity  -  logical  equivalence;  also  equivalence  relation  as  defined  in  3.2.3. 1  below 

^  difference  -  logical  inequivalence 

-i  negation  -  logical  not 

a  conjunction  -  logical  and 

v  disjunction  -  logical  or 

v  exclusion  -  logical  xor 

<8>  possible  -  an  actual  inoperative  fact 

<§>  impossible  -  an  unactual  inoperative  fact 

^  contingent  -  a  conditionally  operant  fact 

H  necessary  -  a  fact  nomologously  related  to  the  operance  of  one  or  more  facts 

0  extrinsic  -  a  fact  nomologously  unrelated  to  the  operance  of  one  or  more  facts 

?  thetic  -  a  positive  fact 

<?  kenonic  -  a  negative  fact 

•  bare  fact  -  positive  identity  soa  of  rank  individual 

•  arbitrary  fact  -  positive  identity  soa  of  rank  taxon 

o  null  fact  -  negative  identity  soa  of  rank  individual 

$  indeterminate  -  negative  identity  soa  of  rank  taxon 

[  ]  optionality  -  soa  extension  configuration  or  element  variation34 
->  indexicalization-as  defined  on  page  31  above 
A  composition  -the  relation  defined  in  3.2.2. 1  below 

1  constitution  -the  relation  defined  in  3. 2. 2. 2  below 

(•)  inherence  -the  relation  defined  in  3. 2. 2. 3  below 

Q  antecedence  -variant  of  the  qualification  relation  defined  in  3. 2. 2. 4  below 

9  consequence  -variant  of  the  qualification  relation  defined  in  3. 2. 2. 4  below 

•  quantification -the  relation  defined  in  3. 2. 2. 5  below 

]  [  involvement  -the  relation  defined  in  3.2.5. 1  below 

Uppercase  letters  (A,B,C,...Z)  will  unless  otherwise  indicated  be  used  as  variables  designating  entities 

of  metasystematic  rank  taxon.  Lowercase  letters  (a,b,c . z)  will  unless  otherwise  indicated  be  used 

as  variables  designating  entities  of  metasystematic  rank  individual. 

34  Square  brackets  within  soa  extension  definitions—  (Rx, (Attribute^  Attribute2  :=  Variant  p  y  Variant  q  ],...))  —are  used  to  indi¬ 
cate  variability  among  extants  of  instances  of  a  relation  type  and  to  define  the  variations;  that  is,  to  mark  the  fact  that 
extensional  variants  or  ‘subtypes’  of  that  relation  type  exist.  Hence  the  expression  [  Attribute2  :=  Attributep  Y  Attribute  q] 
designates  the  fact  that  relation  type  Rx  comprises  two  extensional  subtypes,  as  entities  standing  in  the  Attribute2  posi¬ 
tion  can  be  instances  of  Variantp  XOR  instances  of  Variantq.  The  order  relation  type  defined  in  3. 2. 3. 4  below,  which 
encompasses  four  distinct  extensional  variants,  is  an  illustrative  example. 
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3 . 2 . 1 . 2  Schematic  Metastructure  Requirements 

Several  requirements  pertaining  to  particular  metastructures  are  actually  metatype-specific  config¬ 
urations  of  more  general  requirements  that  apply  to  some  or  all  of  the  metastructures,  albeit  in  dif¬ 
ferent  ways  and  to  differing  degrees.  Schematic  characterizations  of  these  requirements  are 
presented  here. 

I  Polymorphism 

Unless  otherwise  specified,  any  instance  of  any  metastructure  type  can  contain  an  instance  of  any 
other  metatype  as  an  extant  element.  This  is  called  contingent  polymorphism.  Delimitations  of  some 
metastructure  types  or  their  variants  entail  that  their  instances  necessarily  contain  instances  of 
other  metatypes.  This  is  called  necessary  polymorphism. 

Instances  of  any  of  the  17  metatypes  whose  extants  contain  an  indexicalization  element  are 
examples  satisfying  the  contingent  polymorphism  requirement  scheme.  The  qualification  and 
quantification  metatypes  (defined  in  paragraphs  3. 2. 2. 4  and  3. 2. 2. 5)  are  examples  of  metatypes  sat¬ 
isfying  the  necessary  polymorphism  requirement  scheme. 

I  Reflection 

Unless  otherwise  specified,  any  instance  of  any  metastructure  type  can  contain  an  instance  of  that 
same  metatype  as  an  extant  element.  This  is  called  contingent  reflection ,  and  its  realization  in  terms  of 
soa  structures  was  presented  on  page  29  above.  Delimitations  of  some  metastructure  types  or  their 
variants  entail  that  their  instances  necessarily  contain  instances  of  the  same  metatypes.  This  is 
called  necessary  reflection. 

The  non-terminal  variants  of  the  order  metatype  (defined  in  paragraph  3. 2. 3. 4)  are  examples  of 
metatypes  satisfying  the  necessary  reflection  requirement  scheme. 

I  Self-Application 

An  instance  of  a  metastructure  type  may  contain  itself  as  an  element  of  its  extant  if  and  only  if  explic¬ 
itly  specified.  This  is  called  self-application.  Its  realization  in  terms  of  soa  structures  was  also  pre¬ 
sented  on  page  29  above. 

I  Supplementarity 

The  instances  of  some  metastructure  types  or  variants  are  existentially  exiguous.  That  is,  the  exist¬ 
ence  of  a  single  particular  instance  of  these  types  necessarily  entails  the  existence  of  at  least  one 
other  co-incident  instance  of  that  same  type.  This  is  called  extensive  supplementarity.  A  stronger  variant 
of  this  necessarily  entails  the  existence  of  at  least  one  other  co-incident  but  detached  instance  of  that 
same  type.  This  is  called  disjoint  supplementarity. 

Consider  some  metatype  R  and  an  instance  of  it  (R,(x,y))-  If  R  is  extensively  supplementational, 
then  necessarily  there  exists  at  least  one  other  instance: 

(R,(x,z»  v  (R,(z,x». 

If  R  is  disjointly  supplementational,  and  an  instance  of  it  (R,(x,y))  exists,  then  necessarily  there  exists 
at  least  one  other  instance: 

(R,(x,z)):  such  that  -i  (R,(y,z))  and  -i  (R,(z,y))  v  (R,(z,x)):  such  that  -i  (R,(y,z))  and  -i  (R,(z,y))-35 

Rank  taxon  instances  of  the  composition  metatype  are  examples  satisfying  the  extensive  supple¬ 
mentarity  requirement  scheme.  Rank  individual  instances  of  this  metatype  are  examples  satisfying 
the  disjoint  supplementarity  requirement  scheme. 

The  instances  of  some  attributes  delimiting  extensions  of  some  metastructure  types  are  necessar¬ 
ily  minimally  dyadic.  This  is  called  positional  supplementarity.  Consider  some  metatype  R  and  an 
attribute  of  its  extension  Q,  such  that  (R,(A,...,Q,...,S)).  If  Q  is  positionally  supplementational,  then 
every  instance  of  Q  in  the  extant  of  every  instance  of  R  is  necessarily  at  least  a  2-tuple: 


35  This  is  a  generalization  and  informal  articulation  in  soa  syntax  of  the  formally  rendered  Weak  Supplementation  Prin¬ 
ciple  (wsp)  in  Simons  [20.2], 
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(R,<Xi,<qi,q2 . qn).sk)) 

such  that  q1(q2 . qn  all  designate  distinct  entities.  The  substituend  attribute  of  the  equivalence 

metatype  (defined  in  paragraph  3.2.3. 1)  is  one  type  satisfying  the  positional  supplementarity 
requirement  scheme. 

I  Rank  Coordination 

All  elements  of  all  metatype  instances  are  either  of  taxon  or  individual  metasystematic  rank.  How¬ 
ever  as  described  on  page  29  above,  in  general  one  extant  element  in  a  given  soa  can  be  of  a  differ¬ 
ent  rank  than  another  element  within  that  soa.  The  extant  elements  of  instances  of  most 
metastructure  types  must  be  the  same  metasystematic  rank.  For  F-order  instances  this  is  called  nec¬ 
essary  rank  uniformity ;  for  types  encompassing  higher-order  instances  (polymorphic,  reflective,  or 
both),  this  is  called  complete  rank  uniformity. 

For  example,  consider  the  2nd-order  polymorphic  composite  structure  represented  by  the  soa 
below. 

(Composition, ((Constitution, (A, B)), (Constitution, <W,Z))) 

This  soa  represents  a  containment  relation  between  two  dependence  relations,  signifying  that  the 
material  dependence  of  W  on  Z— i.e,  (Constitution, (W,Z))  —is  a  component  element  of  the  material 
dependence  of  A  on  B—  i.e.,  (Constitution, (A, B)).  Complete  rank  uniformity  stipulates  that  either  A,  B,  W, 
and  Z  are  all  of  rank  taxon  or  are  all  of  rank  individual.  The  variation  metatype  (defined  in  para¬ 
graph  3. 2. 3. 3)  is  one  example  satisfying  this  requirement  scheme. 

I  Cyclicity 

A  given  set  of  soa  instances  delineated  by  some  relation  R  can  be  treated  as  a  directed  graph.  One 
graph-theoretic  property  and  its  converse— cyclicity  and  acyclicity— are  invoked  in  some  metastruc¬ 
ture  requirements,  so  we  define  them  here.  An  apparent  form  of  cyclicity,  which  is  an  artifact  of 
our  use  of  soa  schemes  and  rank  taxon  instances  as  delimitation  shortcuts  is  also  defined. 

Cyclicity 

The  extants  of  the  members  of  any  set  of  plural  soas  delimited  by  a  given  relation  R  can  be  rendered 
as  a  single  sequence  of  unique  extant  elements: 

{  <R,<Xi,X2»,  <R,(x2,x3» . <R,<Xn-l,Xn»  }  ->  (x1,x2,x3 . Xn.-|,Xn) 

Any  such  sequence  is  cyclic  under  relation  R  if  and  only  if: 

(RXx^Xg))  and  (R,(x2,x3)>  and  ...  and (R/x^x,)). 

Acyclicity 

Any  such  sequence  is  acyclic  if  and  only  if  it  is  not  cyclic  under  a  given  relation  R. 

Delimitative  Cyclicity 

Any  set  of  uniformly  rank  taxon  soa  instances  {(R,(T1,T2)),(R,(T2,T3)),...,(R,(Tn,T1))}  is  cyclic  given  the 
above  definition.  However,  as  we  stated  in  our  presentation  of  soa  syntax  and  notational  conven¬ 
tions  above,  the  majority  of  soa  instances  of  rank  taxon  represent  facts  of  delimitation  rather  than 
facts  of  specific  relatedness,  and  thus  any  such  cycle  is  ambiguous.  That  is,  it  could  be  interpreted  to 
represent  that  a  member  x  of  taxon  Tj  can  stand  indirectly  in  relation  R  to  itself— i.e.,  that  instances 
of  that  metatype  can  be  cyclic.  On  the  other  hand,  it  could  also  be  interpreted  to  represent  that  some 
member  x  of  taxon  Tj  can  stand  in  relation  R  to  another  member  y  of  taxon  Tj,  but  that  x  cannot  stand 
in  that  relation  to  itself.  This  latter  case,  called  delimitative  cyclicity,  expresses  a  taxonomic  generalization 
concerning  relatedness  of  members  of  taxon  Tj,  in  respect  to  relation  R, 

In  many  cases  constraints  apply  on  members  of  Tj  with  respect  to  standing  in  some  attribute  posi¬ 
tion  of  relation  R.  This  is  called  conditional  rank  taxon  cyclicity.  In  some  cases  there  are  none.  This  is 
called  unconditional  rank  taxon  cyclicity. 
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I  Existential  Status 

Unless  otherwise  specified,  the  complementarity  modality  of  any  instance  of  any  metastructure 
type  can  be  either  thetic  {?)  or  kenonic  (<?),  and  via  indexicalization  instances,  so  can  any  extant 
element  of  any  instance.  However,  as  noted  above,  all  instances  and  extant  elements  are  thetic 
unless  their  complementarity  modalities  are  explicitly  designated  as  kenonic  (£),  Thus  any  soa  W 

soaw:  <R,<x,y» 

lacking  an  explicit  representation  of  complementarity  modality  shall  be  interpreted  as  synonymous 
with  an  explicitly  modalized  soa 

<[].<R.<xi . xn)» 

'(?  I<SOAw,» 

k- 

and  any  indexicalization  instance  designating  an  element  in  an  soaw 
(R,(z, (Indexicalization, <soaw,Y)) 

without  itself  having  an  explicit  representation  of  complementarity  modality  shall  be  interpreted  as 
synonymous  with  an  explicitly  modalized  indexicalization  instance 

(R,(z,([  ], (Indexicalization, <S0Aw,”y”))) 

-(<?  ,(IndexicalizationSoa)) 

(■■■ 

Any  element  of  any  instance  of  any  metastructure  type  can,  unless  otherwise  specified,  be  either 
an  arbitrary  or  an  indeterminate  particular.  Thus  in  accordance  with  the  definitions  of  these  iden¬ 
tity  variants  above,  an  soa  instance  of  the  form 

<R,<x,»» 

shall  be  interpreted  as  a  fact  that  entity  x  stands  in  relation  R  to  any  [arbitrary]  entity  capable  of 
standing  in  the  indicated  monadic  attribute  position,  and  an  soa  instance  of  the  form 

<R,(x,s» 

shall  be  interpreted  as  a  fact  that  entity  x  stands  in  relation  R  to  some  [indeterminate]  entity  capable 
of  standing  in  the  indicated  monadic  attribute  position,  and  finally  that  an  soa  instance  of  the  form 

<R,<x,<»»>  or  <R,<x,<b»> 

shall  be  interpreted  as  a  fact  that  entity  x  stands  in  relation  R  either  to  any  or  some  entities  collec¬ 
tively  capable  of  standing  in  the  indicated  polyadic  attribute  position,  respectively. 

An  extant  element  of  an  instance  of  a  metastructure  type  can  be  a  null  particular  (o)  if  and  only  if 
explicitly  specified. 
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3.2.2  Core  Metastructures 

TYPE 


LU 

cC 


|  1  I  |  COMPOSITION  | 

|  2  I  |  CONSTITUTION 

|~3~|  |  INHERENCE  | 

|  4  |  |  QUALIFICATION 

5  |  |  QUANTIFICATION 


RELATION  OF 


|  Containment 
|  Materiality 

|  Characterization 
|  Conditionality 

|  Multeity 


RELATION  BETWEEN*-*  |  EXAMPLES 


|  Entities*-*Elements 

SYSTEMSOSUBSYSTEMS;  ASSEMBLIES*-*COMPONENTS 

Entities<->Materials 

parts*-* RAW  materials;  COMPOUNDSOCHEM  ELMTS  1 

Entities*->Attributes 

PARTSOFEATURES;  SYSTEMS*-*PERFORMANCE  CHARS 

Relations*->Antecedents 

NEEDS*->REQMTS;  PROCSOlNPUTS;  COMPSTNS<-*EFFIES  | 

Relata*->Quantities 

TPMS*-*TPM  VALUES;  WHERE-USED  QUANTITIES 

Table  2.  Core  Relations 


Figure  4.  Core  Relations 


All  structures  of  all  artifacts  minimally  consist  in  five  fundamental  types  of  relations. 

1.  Composition  —the  relation  of  mereological  containment,  depicted  by  purple  lines  in  above  figure; 

2.  Constitution  —the  relation  of  material  dependence,  (brown  lines,  center); 

3.  Inherence  —the  relation  of  exemplification  (orange  lines,  right  side); 

4.  Qualification  —the  relation  of  conditionality  (Greek  letter  9);  and, 

5.  Quantification— the  relation  of  multeity  (not  shown). 

Any  minimally  correspondent  and  capable  product  representation  system  must  accordingly  imple¬ 
ment  explicit  representations  of  these  five  relation  types  and  provide  facilities  for  instantiating, 
modifying,  and  querying  them. 
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3.2.2. 1  Composition 

Composition  relations,  depicted  by  the  purple  lines  in  Figure  4  above,  are  structures  of  the  form: 
(Composition, (Complex, [Element  :=  Element  v  o  ] )) 

where  Composition  designates  the  Mereological  Containment  taxon;  Complex  designates  entities  that 
contain  component  elements;  where  Element  designates  entities  that  are  component  elements;  and 
where  o  designates  an  instance  of  the  null  particular  variant  of  identity. 

Mereological  Containment  is  a  fundamental  delimitative  element  of  structure.  Composition  is, 
accordingly,  a  critical  metatype  required  for  representing  it.  This  relation  is  one  of  the  two  primary 
types  represented  by  classical  boms— the  other  being  constitution,  defined  in  paragraph  3. 2. 2. 2 
below.  Examples  of  composition  relations  are: 

(A,(Assemblyx,Componenty))  -  a  typical  containment  relation  in  boms 

( A, (Document^ Paragraph^)  -  e.g.,  this  document  and  paragraph  3.3.3 

(A,(Processq,Phaser))  -  e.g.,  Product  Realization  and  Product  Definition 

where  the  symbol  “A”  denotes  composition  as  noted  on  page  33. 

I  Composition  Variants 

There  are  two  infraspecific  variants  of  Containment— Integral  and  Distributive.  Facts  of  the  Integral 
variant  are  relations  between  mereologically  unified  complexes  and  their  components,  such  as  air¬ 
craft  fuselages,  microprocessor  chips,  polysyllabic  words,  and  uninterruptible  multi-phased  pro¬ 
cesses.  Facts  of  the  Distributive  variant  are  relations  between  mereologically  dispersed  complexes 
and  their  components,  such  as  flight  control  subsystems,  brake  systems  on  automobiles,  and  texts 
of  multi-volume  documents.  As  of  this  writing  we  were  unable  to  develop  satisfactorily  definitive 
delimitations  and  identification  keys  for  these  variants.  We  cannot  therefore  stipulate  representa¬ 
tion  of  them  and  their  differences  as  a  requirement  here.  Nevertheless,  the  correlate  complexes  dif¬ 
fer  in  some  of  their  analytic,  constructive,  and  logistical  attributes,  and  once  a  formal 
characterization  of  these  is  developed,  any  minimally  correspondent  and  capable  product  represen¬ 
tation  system  should  be  enhanced  to  explicitly  represent  these  variants  and  to  provide  facilities  for 
differentiating,  instantiating,  modifying,  and  querying  them. 

Integral  variant  complexes  can  be  in  one  of  two  mereological  configurations.  These  are  Parti¬ 
tioned  and  Bracteal.  Entities  standing  in  the  Complex  attribute  position  of  lst-order  composition 
instances  containing  null  particulars  (“o”)  in  their  Element  attribute  positions  are  formalizations  of 
the  Bracteal  configuration  rendered  as  soas.  These  instances  represent  the  fact  that  the  entities  their 
Complex  attribute  positions  are  completely  partless— i.e.,  atomic. 

I  Composition  Requirements 

Composition  relations  are  typically  quantified,  qualified,  and  otherwise  modalized  in  a  variety  of 

1.  Supplementarity 

Rank  taxon  instances  of  the  composition  metatype  are  extensively  supplementational,  as 
defined  in  paragraph  3.2. 1.2  above.  Rank  individual  instances  of  the  composition  metatype 
are  disjointly  supplementational  as  defined  in  that  paragraph. 

2.  Complete  Rank  Uniformity 

Entities  in  the  Complex  and  Element  attribute  positions  in  a  particular  composition  instance 
must  be  of  the  same  metasystematic  rank,  including  all  elements  of  all  extants  of  all  meta¬ 
structure  type  instances  in  every  higher-order  composition  instance. 

3.  Cyclicity 

A  given  set  of  rank  individual  lst-order  composition  instances  must  be  acyclic.  That  is,  a 
particular  complex  cannot  directly  or  indirectly  contain  itself  as  a  component  element. 
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All  reflective  composition  instances  must  be  acyclic.  That  is,  a  particular  composition 
instance  cannot  directly  or  indirectly  contain  itself  as  a  component  element. 

A  given  set  of  rank  taxon  P-order  composition  instances  may  be  conditionally  cyclic.  That 
is,  one  member  of  a  complex  taxon  can  directly  or  indirectly  contain  another  member  of 
that  same  taxon  as  a  component  element,  subject  to  requisite  qualification  condition  rep¬ 
resentation. 

A  given  set  of  composition  instances  containing  at  least  one  polymorphic  higher-order  compo¬ 
sition  instance  may  be  cyclic.  That  is,  an  entity  in  the  extant  of  an  instance  of  a  metastruc¬ 
ture  type  contained  in  the  extant  of  a  composition  instance  can  contain  or  be  contained  by 
that  instance. 

4.  Existential  Status 

No  entity  in  the  Complex  attribute  position  in  a  composition  instance  containing  a  null  in 
its  Element  position  can  be  a  complex  in  any  other  composition  instance.  That  is,  an  atomic 
entity  is  an  indivisible  matter  of  fact. 

3 . 2 . 2 . 2  Constitution 

Constitution  relations,  depicted  by  the  brown  lines  in  Figure  4  above,  are  structures  of  the  form: 
(Constitution, (Superstrate, [Substrate  :=  Substrate  yo])) 

where  Constitution  designates  the  Material  Dependence  relation  taxon;  Superstrate  designates  entities 
that  depend  on  constituent  elements;  where  Substrate  designates  entities  that  are  constituent  enti¬ 
ties;  and  where  o  designates  an  instance  of  the  null  particular  variant  of  identity. 

Like  Containment,  Material  Dependence  is  a  fundamental  delimitative  element  of  structure,  and 
constitution  is,  therefore,  a  crucial  metatype  required  for  representing  it.  This  type  is  the  second  of 
the  two  primary  types  represented  by  classical  boms.  Examples  of  constitution  relations  are: 

(l,(PartTypex,RawMaterialTypey))  -  a  classical  materiality  relation  in  boms 

(_L,(CompositeMatTypew,MatrixMatlTypez))  -  e.g.,  graphite  fiber  and  epoxy 

(l,(CompoundTypeq,ElementTyper))  -  e.g.,  Water  (H20)  and  hydrogen 

where  the  symbol  “_L”  denotes  constitution  as  noted  on  page  33. 

I  Constitution  Variants 

Superstrata  can  be  in  one  of  two  substantival  configurations.  These  are  Heteronomous  and  Inde¬ 
pendent.  Entities  standing  in  the  Superstrate  attribute  position  of  lst-order  constitution  instances 
containing  null  particulars  (“o”)  in  their  Substrate  attribute  positions  are  formalizations  of  the  Inde¬ 
pendent  configuration  rendered  as  soas.  These  instances  represent  the  fact  that  the  entities  their 
Superstrate  attribute  positions  are  completely  self-subsistent— i.e.,  autonomous. 

I  Constitution  Requirements 

1.  Self- Application 

A  particular  constitution  instance  may  contain  itself  as  an  element  in  the  Substrate  attribute 
position  of  its  extant.  That  is,  a  particular  fact  of  material  dependence  may  constitute  itself. 

2.  Supplementarity 

All  self- applicative  rank  taxon  constitution  instances  are  extensively  supplementational, 
as  defined  in  paragraph  3. 2. 1.2  above.  All  self- applicative  rank  individual  constitution 
instances  are  disjointly  supplementational  as  defined  in  that  paragraph.  That  is,  a  particular 
fact  of  material  dependence  may  not  completely  constitute  itself. 
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3.  Existential  Status 

No  entity  in  the  Superstate  attribute  position  of  a  null  substrate  constitution  instance  can 
be  a  superstrate  in  any  other  constitution  instance.  That  is,  an  autonomous  entity  is  an 
ultimate  matter  of  absolute  fact. 


3. 2. 2. 3  Inherence 

Inherence  relations,  depicted  by  the  orange  lines  in  Figure  4  above,  are  structures  of  the  form: 
(Inherence, (Bearer, Character, [Basis  :=  Basis  yo])) 

where  Inherence  designates  Exemplification  relation  taxon;  Bearer  designates  entities  that  are  exam- 
plars  of  characteristics;  where  Character  designates  exemplified  entities;  where  Basis  designates  enti¬ 
ties  that  are  determinants  of  characters  as  exemplified  by  entities;  and  where  o  designates  an 
instance  of  the  null  particular  variant  of  identity. 

Exemplification  is  the  third  fundamental  delimitative  element  of  structure,  and  inherence  is, 
therefore,  a  critical  metatype  required  for  representing  it.  Examples  of  inherence  relations  are: 


((•),(PartTypex,ThroughHoley,SurfaceOfRevolutiona)) 
(w,(Objectw,Colory,Optico-PerceptualStructd )) 
(w,(7075-T7,TensileStrength,Microstructure^ )) 
(w,(Processz,Reliability[.98],lmplementationConfig0 )) 


-  a  paradigm  geometric  feature 

-  a  paradigm  ‘secondary  quality’ 

-  a  material  property 

-  a  process  effectiveness  metric 


((•), (results  1  .fm,“  CD  Linherence  J’,7art/coreMetaTable.pct”))  -  i.e.,  Fig  4  artwork,  imported  by  reference 

where  the  symbol  “W”  denotes  constitution  as  noted  on  page  33. 

Delineating  features  of  entities  such  as  topological  and  geometrical  form,  physical  properties,  and 
other  derivative  traits,  inherence  is  a  formalization  of  structures  implemented  in  geometric  model¬ 
ing,  structural  analysis,  and  imaging  systems,  and  is  not  represented  by  classical  boms.  Nevertheless, 
representing  this  relation  and  its  related  entity  types  as  integral  elements  of  structure  is  directly 
entailed  by  the  amplitude  needs  described  in  paragraphs  3.1.1  and  3.1.2  above.  That  is,  particular 
divergences  between  multiple  genitive  configurations  of  artifacts  are  grounded  in  specific  artifact 
characteristics,  as  we  implicitly  demonstrated  in  our  discussions  of  articulation,  factoring,  and  con¬ 
solidation.  Hence  representing  these  characteristics  and  the  relations  they  stand  in  is  a  prerequisite 
of  representing  inter-configuration  differences  as  relations  between  configurations.36  Moreover, 
artifacts  and  their  elements,  including  their  specific  characteristics,  are  all  solutions  to  instrumental 
requirements,  as  we  pointed  out  in  our  discussion  of  the  requirements  representation  need  on  page 
24.  Thus  representing  all  the  elements  of  artifact  structure— including  specific  artifact  characteris¬ 
tics— is  a  prerequisite  of  representing  the  physical  synthesis  of  needs  and  requirements  as  relations 
between  these  and  the  elements  and  characters  of  artifacts  that  fulfill  them. 

I  Inherence  Variants 

There  are  two  infraspecific  variants  of  Exemplification— Faceted  and  Dispositional.  Facts  of  the  Fac¬ 
eted  variant  are  relations  between  entities  and  spatial  features,  such  as  surface  deformations  and 
protrusions,  holes,  faces,  and  other  varieties  of  topological  and  geometrical  form.  Facts  of  the  Dis¬ 
positional  variant  are  relations  between  entities  and  properties,  such  as  material,  functional,  eco¬ 
nomic,  and  psychological  attributes— indeed  any  variety  of  determinable  magnitude.  Facts  of  the 
Dispositional  variant  are  represented  by  inherence  instances  with  quantification  instances37  in 
their  Character  attribute  positions.  That  is,  dispositional  exemplifications  are  externalized  manifes¬ 
tations  of  quantities,  in  the  most  general  sense  of  that  term.  Facts  of  the  Faceted  variant  are  repre¬ 
sented  by  those  with  instances  of  any  other  metatype  in  their  Character  attribute  positions— 
particularly  those  with  identity  instances  as  characteristics— these  being  explicit  objectifications  of 


36  Our  formalizations  of  these  relations  and  the  roles  of  inherence  in  those  are  presented  in  paragraphs  3.2.4. 1,  3. 2. 4. 2, 
and  3. 2. 4. 3  below. 

37  Quantification  is  defined  in  paragraph  3. 2. 2. 5  below. 
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features  qua  entities. 

Entities  exemplified  by  facts  of  either  Exemplification  variant  can  be  in  one  of  the  configura¬ 
tions.  These  are  Attributive  and  Intrinsic.  Entities  standing  in  the  Character  attribute  position  of 
inherence  instances  containing  any  instances  other  than  null  particulars  (“o”)  in  their  Basis 
attribute  positions  are  formalizations  of  the  Attributive  configuration  rendered  as  soas.  The  first 
two  examples  above  (i.e.,  PartTypex  and  Objectw)  are  representative  of  this  configuration  and  the  type 
of  characteristic  that  distinguishes  it.  These  characteristics  are  ascriptive— they  are  externalized  man¬ 
ifestations  of  entities  in  Basis  attribute  positions  by  entities  in  Bearer  attribute  positions.  Entities 
standing  in  the  Character  attribute  position  of  inherence  instances  containing  null  particulars  (“o”) 
in  their  Basis  attribute  positions  are  formalizations  of  the  Intrinsic  configuration  and  the  type  of 
characteristic  that  marks  it.  These  characteristics  are  primitives— either  within  the  scope  of  a  given 
representational  context  or  system,  or  in  the  actual  world.  The  properties  of  geometric  primitives  in 
modeling  systems  are  examples  of  the  former;  the  speed  of  light  in  a  vacuum  c  is  an  example  of  the 
latter. 

Any  minimally  correspondent  and  capable  product  representation  system  must  implement 
explicit  representations  of  these  Exemplification  variants  and  configurations  and  provide  facilities 
for  differentiating,  instantiating,  modifying,  and  querying  them. 

I  Inherence  Requirements 

1.  Complete  Rank  Uniformity 

Entities  in  the  Bearer  and  Character  attribute  positions  in  a  particular  inherence  instance 
must  be  of  the  same  metasystematic  rank,  including  all  entities  in  those  attribute  positions 
in  all  extants  of  all  metastructure  type  instances  in  every  higher-order  inherence  instance. 

Entities  in  the  Basis  attribute  position  in  a  particular  inherence  instance  with  bearers  rank 
taxon  entities  in  its  Bearer  and  Character  attribute  positions  may  be  of  rank  individual. 

2.  Cyclicity 

A  given  set  of  rank  individual  P-order  inherence  instances  must  be  acyclic.  That  is,  a  par¬ 
ticular  entity  must  either  be  an  exemplar,  an  exemplified  characteristic,  or  a  genitive  basis 
of  a  characteristic  as  exemplified  by  a  given  individual  entity. 

All  reflective  inherence  instances  must  be  acyclic.  That  is,  a  particular  inherence  instance 
cannot  directly  or  indirectly  contain  itself  as  a  component  element. 

A  given  set  of  rank  taxon  P-order  inherence  instances  can  be  conditionally  cyclic.  That  is, 
two  members  of  the  same  taxon  can  stand  in  the  Bearer,  Character,  or  Basis  attribute  posi¬ 
tions  of  a  particular  inherence  instance,  subject  to  requisite  qualification  condition  repre¬ 
sentation. 

A  given  set  of  inherence  instances  containing  at  least  one  polymorphic  higher-order  inher¬ 
ence  instance  may  be  cyclic. 

3.  Existential  Status 

No  entity  in  the  Character  attribute  position  in  a  inherence  instance  containing  a  null  in  its 
Basis  position  can  be  a  characteristic  in  any  Attributive  configuration  inherence  instance. 
That  is,  an  atomic  entity  is  an  indivisible  matter  of  fact. 
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3 . 2 . 2 . 4  Qualification 

Qualification  relations  are  structures  of  the  form: 

(Qualification, (Correlate, [Evolute  :=  Evolute  v  s], [Adject  :=  Adject  v  (Adject  Adject n)  y  o  ] )) 

where  Qualification  designates  the  Conditionality  taxon;  Correlate  designates  either  contingently  oper¬ 
ant  entities  or  determinants  of  contingently  operant  entities;  where  Evolute  designates  transforma¬ 
tion  instances  representing  ontogenetic  elements  of  correlate  entities  as  defined  in  paragraph 

3. 2. 3. 5  below;  where  Adject  j  designates  an  entity  that  is  nomologically  related  to  the  operance  status 
of  its  correlate  entity;  and  where  Null  designates  an  instance  of  the  null  particular  variant  of  iden¬ 
tity.  This  relation  type  is  a  formalization  of  “causal  dependence”  or  contingency  and  therefore  is, 
strictly  speaking,  a  co-variant  of  constitution.  Its  variants,  configurations,  and  relata— one  of  these 
latter  being  a  formalization  of  “effectivity”— are  essential  for  representing  provisionally  or  periodi¬ 
cally  operant  matters  of  fact  and  are,  accordingly,  cornerstones  of  representational  correspondence. 

I  Qualification  Variants 

There  are  two  positional  variants  of  Conditionality— Subvenient  and  Supervenient.  There  are  two 
distinct  material  variants  of  the  Evolute  attribute  of  both  positional  Conditionality  variants.  These  are 
Particular  and  Indeterminate.  There  are  two  distinct  material  variants  of  the  Adject  attribute  of  both 
Conditionality  variants.  These  are  Individual  and  Relational.  There  are  two  alternative  extensional 
forms  of  the  Adject  attribute.  These  are  Univalent  and  Multivalent.  Facts  of  the  Univalent  forms  of 
any  variant  can  be  in  one  of  two  distinct  configurations— Nomologous  or  Autarkic.  Facts  of  the  Mul¬ 
tivalent  forms  are  necessarily  Nomologous.  There  are  two  intensional  variants  of  the  Nomologous 
configurations  of  Subvenient  and  Supervenient  Conditionality.  These  are  Acception  and  Exception. 

Any  minimally  correspondent  and  capable  product  representation  system  must  implement 
explicit  representations  of  these  Conditionality  variants,  forms,  and  configurations  as  subtypes  of 
the  qualification  relation  type  and  provide  facilities  for  differentiating,  instantiating,  modifying, 
and  querying  them.  Figure  31  in  Attachment  2  graphically  depicts  these  structures  in  some  detail. 

1.  Antecedence 

Antecedence  relations  are  structures  of  the  form: 

(Antecedence,  (Superject,  I  nceptor,  [Antecedent  :=  Antecedent  y  (Antecedent^...,  Antecedent  n)  y  o  ] )) 

where  Antecedence  designates  the  Subvenient  variant  of  the  Conditionality  taxon;  where 
Superject  designates  contingently  operant  entities;  where  Inceptor  designates  an  Inception 
phase  transformation  instance  in  the  ontogeny  of  the  superject  entity;  and  where  Anteced¬ 
ent  j  designates  a  causal  prerequisite  for  operance  of  the  superject  entity. 

Antecedence  instances  with  composition,  constitution,  or  transformation  instances  in 
their  Superject  positions  are  formalizations  of  component,  raw  material,  or  version  “effec- 
tivities”  in  boms.  Specifically,  antecedence38  instances  with  thetic  (‘V”)  rank  taxon 
composition  instances  in  their  Superject  positions  and  at  least  one  relation  instance  an  Ante- 
cedentj  position  are  formalizations  of  a  diverse  class  of  phenomena  commonly  called  “struc¬ 
ture  effectivity,”  a  specific  and  very  common  form  of  intrinsic  variation— namely, 
compositional  contingency.  Such  modalized  composition  instances  represent  conditional  Contain¬ 
ment  relationships;  that  is,  relationships  between  complexes  and  their  components  that  are 
only  operant  (“effective”)  under  certain  specific  conditions.  For  example,  the  composition 
instance  in  the  structure 

( [  l  (A,(F-18,ElectronicCounterMeassuresPod))) 

-(&(  AsoA,«,RadarSupressionFunction)) 


38  This  relation  type  is  defined  in  paragraph  3. 2. 2. 4  below. 
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reopresents  the  fact  that  members  of  the  F-18  taxon  stand  in  composition  relations  to  mem¬ 
bers  of  the  ElectronicCounterMeassuresPod  taxon.39  However,  the  presence  of  the  modalizing 
antecedence  instance  marks  this  relationship  as  contingent.  That  is,  this  Containment  rela¬ 
tionship  is  not  canonically  operant  or  invariant  among  all  members  of  the  F-18  and  EcMPod 
taxa,  and,  accordingly,  not  all  f-18s  contain  ecm  pods  as  components.  A  particular  f-18  will 
contain  an  ecm  pod  if  and  only  if  the  RadarSupressionFunction  element  of  the  f-18  functional 
architecture  has  been  invoked—  it  is  to  perform  an  ew  role  in  the  context  of  a  mission. 

2.  Consequence 

Consequence  relations  are  converses  of  antecedence  relations,  and  are  structures  of  the 
form: 

(Consequence, (Subject, Continuance, [Consequent  :=  Consequent  v  (Consequent  1r„,  Consequent  n)  y  o  ] )) 

where  Consequence  designates  the  Supervenient  variant  of  the  Conditionality  taxon;  where 
Subject  designates  determinants  of  contingently  operant  entities;  where  Continuance  desig¬ 
nates  an  Continuation  phase  transformation  instance  in  the  ontogeny  of  the  subject 
entity;  and  where  Consequent  j  designates  a  causal  successor  of  the  operance  of  the  subject 
entity. 

3 . 2 . 2 . 5  Quantification 

Quantification  relations  are  structures  of  the  form: 

(Quantification, (Datum, Magnitude, System, Unit,  Quantity)) 

where  Quantification  designates  the  Multeity  taxon;  where  Datum  designates  entities  that  fall  under  a 
quantificational  scope;  where  Magnitude  designates  specific  variants  of  the  Multeity  taxon;  where 
System  designates  a  mensuration  scheme  delimiting  Multeity  taxon  variants;  Unit  designates  a  dis¬ 
crete  divisionalization  scheme  for  one  or  more  magnitudes;  and  where  Quantity  designates  a  particu¬ 
lar  number  of  units.  Examples  of  quantification  relations  are: 

(#>((~>>(('MC-1 30,  Engine)),  2»,  Containment,  Unitary,  4» 

(#>((^>((-L, (Water,  Hydrogen)),  2»,  Substance,  SI,  Mole,  2» 

(#,((^,((w,(PartTx,Holey,!s»,2)),Cylindricity,ANSiY1 4.5, Inches, .005)) 

(#,((A,(C-130,AftPluf)),Location,C-130Grid,StationLine,158)) 

where  the  symbols  and  »”  respectively  denote  quantification,  indexicalization, 

composition,  constitution,  and  inherence  as  noted  on  page  33. 

Quantification40  instances  (“#”)  with  Datum  positions  containing  indexicals  (“-»”)  to  Element  posi¬ 
tions  in  rank  taxon  composition  instances  are  formalizations  of  “where  used  quantities,”  a  perva¬ 
sive  and  essential  characteristic  of  Containment  represented  by  parts  lists  on  engineering  drawings 
and  by  boms.  Thus  the  soas  in  the  structure 

([  ],  (A,(C-130,AllisonTurbopropTypex))) 

-(#,((y(^soa,  2»,  Multiplicity,  MFS,  Individual,' 4» 

represent  the  facts  that  members  of  the  C-130  taxon  stand  in  composition  relations  to  members  of 
the  AllisonTurbopropTypex  taxon,  and  that,  via  the  quantification  instance  modalizing  that  composition 
instance,  every  member  of  the  former  contains  exactly  4  members  of  the  latter— in  other  words, 
that  each  c-130  contains  four  Allison  turboprop  engines  as  component  elements.41  Any  minimally 
correspondent  and  capable  product  representation  system  must  provide  facilities  for  instantiating, 

39  The  f-18  airframe  contains  a  centerline  pylon  that  is  used  to  attach  ordnance  and  certain  mission- specific  hardware 
to  the  airplane.  The  ecm  pod,  which  is  basically  an  elongated  bullet-shaped  tank  stuffed  full  of  radar  jamming  and 
other  ew  equipment,  is  a  case  in  point. 

40  This  relation  type  is  defined  in  paragraph  3. 2. 2. 5  below. 
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modifying,  and  querying  quantifications  of  composition  instances,  regardless  of  metasystematic 
rank.42 

Quantification  instances  with  Datum  positions  containing  indexicals  to  Substrate  positions  in  rank 
taxon  constitution  instances  are  formalizations  of  “make  from  quantities,”  a  pervasive  and  essen¬ 
tial  characteristic  of  Materiality  represented  by  materials  lists  on  engineering  drawings  and  by  boms. 
Thus  the  soas  in  the  structure 

([  ],  (l,(MountingBracketx,MIL-S-6758/4130))) 

-(#,((^,(J-SOA,2)),Mass,SI,Gram,50)) 

represent  the  facts  that  members  of  the  MountingBracketx  taxon  stand  in  constitution  relations  to 
members  of  the  4130  variant  of  the  MIL-S-6758  taxon  (i.e.,  chrome  steel),  and  that,  via  the  quantifi¬ 
cation  instance  modalizing  that  constitution  instance,  every  member  of  the  former  is  made  out  of 
50  grams  of  the  latter— in  other  words,  that  each  individual  mounting  bracket  of  that  type  contains 
four  Allison  turboprop  engines  as  elements.43  Any  minimally  correspondent  and  capable  product 
representation  system  must  provide  facilities  for  instantiating,  modifying,  and  querying  quantifica¬ 
tions  of  rank  taxon  composition  instances. 

3.2.3  Intrinsic  Adjunct  Metastructures 
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EXAMPLES 
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Substitutionality 

Relata<-*Substituends 
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ALTERNATION 

Optionality 
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Relata*->Alternatives 
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VARIATION 
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1 

Baselines*-* Variants 

|  jsf<-*(af  variant, stol  variant) 
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EntitiesoPositions 

ASSEMBLY  ORDER;  SERVICE  PRECEDENCE 

2°J. 

TRANSFORMATION 

Development 

1 

EntitiesoStates 

C-130H*-*C-130j;  LINUX  KERNEL  V2.0.3<-*V2.0.4 

Table  3.  Intrinsic  Relations 


All  extrinsic  and  processual  variabilities  within  the  structures  of  artifacts  minimally  consist  in  five 
fundamental  types  of  relations. 


1.  Equivalence 

2.  Alternation 

3.  Variation 

4.  Order 

5.  Evolution 


—the  relation  of  substitutionality; 
—the  relation  of  optionality; 

—the  relation  of  diversity; 

—the  relation  of  positionality;  and, 
—the  relation  of  change. 


Any  minimally  correspondent  product  representation  system  must  implement  representations  of 
these  five  relation  types  and  provide  facilities  for  instantiating,  modifying,  and  querying  them. 
Examples  of  entities  standing  in  these  relations  are  depicted  in  the  table  at  the  top  of  Figure  33  in 
Attachment  2. 


41  The  actual  matters  of  fact  are  of  course  much  more  complicated  than  those  represented  by  this  simplistic  example. 
For  instance,  c-130’s  in  the  process  of  being  built  don’t  contain  even  one  engine  (let  alone  4)  until  they  reach  a  certain 
stage  of  assembly,  so  the  quantification  instance  itself  should  be  qualified  by  an  antecedence  instance  representing 
this  effectivity. 

42  Quantifications  of  rank  individual  composition  instances  are  frequently  employed  to  represent  particular  but  indi¬ 
vidually  variable  numbers  of  components  in  serialized  “as-built”  and  “as-repaired”  boms. 

43  The  actual  matters  of  fact  are  of  course  much  more  complicated  than  those  represented  by  this  simple-minded  exam¬ 
ple.  For  instance,  c-130’s  in  the  process  of  being  built  don’t  contain  even  one  engine  (let  alone  4)  until  they  reach  a 
certain  stage  of  assembly,  so  the  qualification  instance  should  itself  be  qualified  by  an  antecedence  instance  repre¬ 
senting  its  effectivity. 
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3 . 2 . 3 . 1  Equivalence 


Figure  5.  Equivalence  Relations 


Equivalence  relations,  depicted  by  the  circular  ring  of  green  lines  in  Figure  5  below,  are  structures  of 
the  form: 

(Equivalence, (Substituend1,Substituend2,...n)) 

where  Equivalence  designates  the  Substitutionality  taxon;  and  where  Substituendj  designates  an  entity 
that  is  completely  interchangeable  with  at  least  one  other  entity. 

3. 2. 3. 2  Alternation 

Alternation  relations,  depicted  by  the  blue  lines  bottom  left  in  the  Figure  6  below,  are  structures  of 
the  form: 

(Alternation,(Context,(Alternant1,Alternant2,...n))) 

where  Alternation  designates  the  Optionality  taxon;  where  Context  designates  entities  situating  the 
alternation;  and  where  Alternantj  designates  an  entity  that  is  form,  fit,  function  congruent  with  at  least 
one  other  entity. 


Figure  6.  Alternation  Relations 
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3. 2. 3. 3  Variation 


Variation  relations,  depicted  by  the  green  lines  upper  left  in  the  above  figure,  are  structures  of  the 
form: 

(Variation, (Baseline, (Divergence^..., Divergence^  , Variant)) 

where  Variation  designates  the  Infraspecific  Variety  taxon;  where  Baseline  designates  entities  that  are 
progenitor  or  canonical  taxonomic  configurations;  where  Variant  designates  entities  that  are  deriva¬ 
tive  configurations  of  progenitor  or  canonical  configurations;  and  where  Divergencej  designates  an 
additive  or  subtractive  delta  between  variants  and  their  respective  baseline  configurations. 

3. 2. 3. 4  Order 


Figure  8.  Order  Relations 


Order  relations,  depicted  by  the  curved  grey  lines  in  the  above  figure,  are  structures  of  the  form: 

(Order, (Ordinate, [Ordinal  :=  Ordinal  v  (Ordinal^. ..,Ordinaln)  v  o  ] )) 

where  Order  designates  the  Positionality  taxon;  Ordinate  designates  entities  standing  in  some  relative 
position  with  respect  to  others;  where  Ordinalj  designates  an  instance  of  the  order  relation  type;  and 
where  o  designates  an  instance  of  the  null  particular  variant  of  identity. 
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I  Order  Variants 

There  are  two  major  extensional  variants  of  Positionality— Contiguous  and  Furcate.  There  are  two 
principal  alternative  forms  of  Contiguous  Positionality.  These  are  Consecutive  and  Concurrent. 
There  are  two  principal  alternative  forms  of  Furcate  Positionality.  These  are  Excessional  and  Ingres- 
sive.  Facts  of  the  Consecutive  form  of  the  Contiguous  variant  and  the  Ingressive  form  of  the  Furcate 
variant  can  be  in  one  of  two  configurations— Catenary  and  Terminal.  Any  minimally  correspondent 
and  capable  product  representation  system  must  accordingly  implement  explicit  representations  of 
these  four  variants  and  two  configurations  as  subtypes  of  the  order  relation  type  and  provide  facil¬ 
ities  for  instantiating,  modifying,  and  querying  them. 

1.  Sequence 

Sequence  relations  are  structures  of  the  form: 

(Sequence, (Ordinate, [Ordinal  :=  Successor  v  o  ] )) 

where  Sequence  designates  the  Consecutive  form  of  the  Contiguous  variant  of  the  Position¬ 
ality  taxon;  where  Ordinate  designates  entities  standing  in  a  position  within  a  contiguous 
series;  and  where  Successor  designates  an  instance  of  the  order  relation  type.  Sequence 
instances  containing  order  relation  instances  in  the  Ordinal  attribute  position  represent 
facts  related  to  proximate  facts  in  an  ordering.  Those  with  null  particulars  in  that  position 
represent  facts  terminating  an  ordering.  Examples  of  sequence  relations  are: 

Seqj:  (Sequence, ((Composition, (X,Y)),Seqj )) 

Seqj:  (Sequence, ((Composition, (X,Z)),o))  (e.g.,  assembly  ordering  for  X); 

Seqj:  (Sequence, (Processq, Seqj )) 

Seqj:  (Sequence, (Processw,Seqk))  (e.g.,  process  execution  ordering); 

Seqj:  (Sequence, ((Composition, (X,Y)), Seqj )) 

Seqj:  (Sequence, ((Composition, (X,Z)),o))  (e.g.,  assembly  ordering  for  X); 

2.  Coincidence 

Coincidence  relations  are  structures  of  the  form: 

(Coincidence, (Ordinate, (Coincident1,Coincident2,...n ))) 

where  Coincidence  designates  the  Concurrent  form  of  the  Contiguous  variant  of  the  Position¬ 
ality  taxon;  Ordinate  designates  entities  that  are  in  a  parallel  position  with  others  in  a  con¬ 
tiguous  series;  and  where  Coincidentj  designates  an  instance  of  the  order  relation  type. 

3.  Ramification 

Ramification  relations  are  structures  of  the  form: 

(Ramification, (Ordinate, (Disjunct1,Disjunct2,...n))) 

where  Ramification  designates  the  Excessional  form  of  the  Furcate  variant  of  the  Positionality 
taxon;  Ordinate  designates  entities  that  are  incident  to  the  same  position  in  a  contiguous 
series;  and  where  Disjunct  designates  an  instance  of  the  order  relation  type. 

4.  Convergence 

Convergence  relations  are  structures  of  the  form: 

(Convergence,  (Ordinate,  (Precessor1,Precessor2,...n),  [Successor  v  o  ] )) 

where  Convergence  designates  the  Ingressional  form  of  the  Furcate  variant  of  the  Positional¬ 
ity  taxon;  Ordinate  designates  entities  that  are  incident  to  the  same  position  in  a  contiguous 
series;  and  where  Precessorj  and  Successor  designate  instances  of  the  order  relation  type. 
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3 . 2 . 3 . 5  Transformation 


Figure  9.  Evolution  Relations 


Transformation  relations,  depicted  by  the  red  lines  in  the  above  figure,  are  structures  of  the  form: 

(Transformation, (Subject, [Delta  :=  Delta y  o ],[Evolute  :=  Evolute y  (Evolute1,...,Evoluten)  vo])) 

where  Transformation  designates  the  Development  taxon;  where  Delta  designates  relations  of  additive 
or  subtractive  change;  where  Evolute,  designates  an  instance  of  the  transformation  relation  type; 
and  where  null  designates  an  instance  of  the  null  particular  variant  of  identity. 

Transformation  is,  in  actuality,  a  variant  of  the  order  metatype.  That  is,  transformation  is  position¬ 
ality  of  change,  as  opposed  to  any  other  ordinate  type.  It  is  defined  here  as  a  distinct  metasystematic 
peer  of  order  because  of  its  central  role  in  delimiting  the  structures  of  ontogeny— i.e.,  versioning. 
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3.2.4  Extrinsic  Adjunct  Metastructures 


TYPE  |  RELATION  OF  | 


pM~|  [  ARTICULATION 

12  |  FACTORIZATION 

13  |  CONSOLIDATION 


Separation 
Abstraction 
|  Integration 


RELATION  BETWEENO 


EntitiesoRealizations 


Table  4.  Extrinsic  Relations 


EXAMPLES 


NOZZLE  ASSEMBLY<~>(tHROAT, CHAMBER, EXIT  CONE)  | 

I  (gear.,, GEAR;, GEARn)<~>GEAR  BLANK  | 

(CHIPStBOARDStHOUSING)<-> AVIONICS  LRU _ I 


Figure  10.  Extrinsic  Relations 


All  divergences  between  multiple  genitive  artifact  configurations  minimally  consist  in  three  funda¬ 
mental  types  of  relations. 

1.  Articulation  —the  relation  of  separation; 

2.  Factorization  —the  relation  of  abstraction;  and, 

3.  Consolidation  —the  relation  of  integration. 

Any  minimally  correspondent  product  representation  system  must  accordingly  implement  explicit 
representations  of  these  three  relation  types  and  provide  facilities  for  instantiating,  modifying,  and 
querying  them.  Examples  of  entities  standing  in  these  relations  are  depicted  in  the  table  at  the  top 
of  Figure  33  in  Attachment  2.  A  detailed  discussion  of  them  is  presented  in  Simons  and  Dement  [21]. 

3 . 2 . 4 . 1  Articulation 


Figure  11.  Articulation  Relations 

Articulation  relations,  depicted  by  the  orange  lines  between  the  rocket  nozzle  image  on  the  left 
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and  right  in  the  Figure  11,  are  structures  of  the  form: 

(Articulation,  (Choate,  [Intrastice  :=  Intrastice  v  (I  ntrastice-, ntrasticen  ],  (Segment  ^Segment  2,.--,n))) 

where  Articulation  designates  the  Separation  variant  of  the  Transposition  taxon;  where  Choate  desig¬ 
nates  unitary  elements  of  a  particular  choate  entity  configuration;  where  Intrastice,  designates  an 
entity  constituting  an  actual  or  potential  processual  interdiction  with  respect  to  a  second  configu¬ 
ration  of  a  given  choate  entity  configuration;  and  where  Segment  j  designates  an  entity  constituting  a 
partition  of  the  choate  entity  in  the  second  configuration. 


3 . 2 . 4 . 2  Factorization 


Figure  12.  Factorization  Relations 


Factorization  relations,  depicted  by  the  orange  lines  between  the  gears  on  the  left  and  the  gear 
blank  on  the  right  in  the  Figure  12,  are  structures  of  the  form: 

(Factorization,  ((Cognate1,Cognate2,...n),[Coenomorph  :=  Coenomorph  v  (Coenomorph1,...,Coenomorphn)],  Factor)) 

where  Factorization  designates  the  Abstraction  variant  of  the  Transposition  taxon;  where  Cognatej  des¬ 
ignates  an  entity  that  is  phyletically  related  to  other  elements  of  a  particular  entity  configuration; 
where  Coenomorphj  designates  a  shared  character  among  cognate  entities;  and  where  Factor  designates 
an  entity  constituting  a  coincident  bearer  of  one  or  more  coenomorphs  in  a  second  configuration 
of  a  given  entity. 

3 . 2 . 4 . 3  Consolidation 


Consolidation  relations,  depicted  by  the  orange  lines  between  the  three  elements  on  the  left  and 
the  one  on  the  right  in  Figure  13,  are  structures  of  the  form: 
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(Consolidation, ({Isolate-,  ,lsolate2,  ■  -  -  n), [Interstice  :=  Interstice  y  {Interstice-, , . . . , Interstice  n  )],Combinant )) 

where  Consolidation  designates  the  Abstraction  variant  of  the  Transposition  taxon;  where  Isolate,  desig¬ 
nates  an  entity  that  is  discontiguous  with  other  elements  of  a  particular  entity  configuration;  where 
Interstice,  designates  separation  between  discontiguous  entities;  and  where  Combinant  designates  an 
entity  constituting  an  integral  entity  encompassing  discontiguous  entities  in  a  second  configuration 
of  a  given  entity. 


3.2.5  Intertypic  Adjunct  Metastructures 

TYPE  |  RELATION  OF  |  RELATION  BETWEEN**  \  _ EXAMPLES 


y 

14  |  INVOLVEMENT 

Participation 

Continuants^>Occurrents 

PRODUCTS<->FUNCTIONS;  ATTRIBUTES<->TEST  PROCS 

h  | 

U 

z 

a. 

> 

1 5  |  CAPACITATION 

Provisionment 

lnvolvements<->Tools;  Agencies 

F-18E/F  assembly<-»{fixtures;  jigs;  assemblers} 

z> 

c2 

Q 

tU 

h- 

1  6  |  REPRESENTATION 

Objectification 

Entities<->Representations 

prdctso{eng  dwgs.data};  procs<h>{tech  mnls.code}  I 

< 

Z 

17  |  DESIGNATION 

Nominalization 

Entities<->Designators 

PARTS<-»PART  NUMBERS;  AIRCRAFTOTAIL  NUMBERS 

Table  5.  Intertypic  Relations 


All  structures  of  all  artifacts  minimally  consist  in  five  fundamental  types  of  relations. 

1.  Involvement  —the  relation  of  participation ; 

2.  Capacitation  —the  relation  of  provisionment; 

3.  Representation— the  relation  of  objectification;  and, 

4.  Designation  —the  relation  of  nominalization. 

Any  minimally  correspondent  product  representation  system  must  accordingly  implement  explicit 
representations  of  these  four  relation  types  and  provide  facilities  for  instantiating,  modifying,  and 
querying  them.  Examples  of  entities  standing  in  these  relations  are  depicted  in  the  table  at  the  top 
of  Figure  33  in  Attachment  2. 

3 . 2 . 5 . 1  Involvement 
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Involvement  relations,  depicted  by  the  orange  ‘elbow’  line  in  Figure  14,  are  structures  of  the  form: 
(Involvement, (Type,  Intension,  Extension)) 

where  Involvement  designates  the  Participation  taxon;  where  Type  designates  taxa  in  a  given  represen¬ 
tation  metasystem;  where  Intension  designates  entities  constituting  context  elements  of  facts  of  rep¬ 
resentation  system  types;  and  where  Extension  designates  entities  constituting  elements  in  the 
extants  of  those  facts. 

3 . 2 . 5 . 2  Capacitation 
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Figure  15.  Capacitation  Relations 


Capacitation  relations,  depicted  by  the  orange  arc  line  in  Figure  15,  are  structures  of  the  form: 
(Capacitation, (Involvement, Means, Yield)) 

where  Capacitation  designates  the  Provisionment  taxon;  Involvement  designates  instances  of  the 
involvement  relation  type  as  defined  in  paragraph  3.2.5. 1  above;  Means  designates  entities  compris¬ 
ing  implemental  mechanisms  or  agencies;  and  where  Yield  designates  entities  constituting  actualiza¬ 
tions  of  antecedents  (conditions  or  inputs)  of  involvement  relation  instances. 

3 . 2 . 5 . 3  Representation 

Representation  relations,  depicted  by  the  orange  lines  in  the  Figure  16,  are  structures  of  the  form: 
(Representation, (Concept, Content, Object)) 

where  Representation  designates  the  Objectification  taxon;  where  Concept  designates  taxa  delimiting 
facts  of  intentional  content;  where  Content  designates  objectified  facts— entities  that  are  representa¬ 
tions  of  entities;  and  where  Object  designates  represented  entities.  A  detailed  discussion  of  repre¬ 
sentation  is  presented  in  Smith  [22]. 
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Figure  16.  Representation  Relations 


3 . 2 . 5 . 4  Designation 
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Figure  17.  Designation  Relations 


Designation  relations,  depicted  by  the  orange  lines  in  the  above  figure,  are  structures  of  the  form: 
(Designation, (Context,  Designator,  Referent)) 

where  Designation  designates  the  Nominalization  variant  of  the  Objectification  taxon;  Context  desig- 
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nates  taxa  delimiting  nominal  facts;  where  Designator  designates  entities  that  are  denominations  of 
entities;  and  where  Referent  designates  denominated  entities. 

3.2.6  Table  of  Metastructure  Schemata 

Table  6.  Metastructure  Schemata 

(Composition, (Complex, [Element  :=  Element  vo])) 

(Constitution, (Superstrate, [Substrate  :=  Substrate  y  o  ] )) 

(Inherence, (Bearer, Character, [Basis  :=  Basis  y  o  ] )) 

(Qualification, (Correlate, [Evolute  :=  Evolute  y  ®  ], [Adject  :=  Adject  y  (Adject  i . Adjectn)  y  o  ] )) 

(Antecedence, (Superjectjnceptor, [Antecedent  :=  Antecedent  y  (Antecedent! . Antecedent )  y  o  ] )) 

(Consequence, (Subject, Continuance, [Consequent  :=  Consequent  y  (Consequent : Consequent,, )  y  o  ] )) 

(Quantification, (Datum, Magnitude, System, Unit,  [Value:=  Value  y  Range  y  Soa]  )) 

(Equivalence, (Substituend!  ,Substituend2, . . .  n )) 

(Alternation, (Context, (Alternant!  ,Alternant2,  ...„») 

(Variation, (Baseline, (Divergence! . Divergence^  .Variant)) 

(Order, (Ordinate, [Ordinal  :=  Ordinal  y  (Ordinal! . Ordinal  n )  y  o  ] )) 

(Sequence, (Ordinate, [Ordinal  =  Successor  vo])) 

(Coincidence, (Ordinate, (Coincident!  ,Coincident2, . . .  n ))) 

(Ramification, (Ordinate, (Disjunct! ,  Disjunct . Disjunctn ))) 

(Convergence,(Ordinate,(Precessor!,Precessor2,...n ), [Successor  v  o  ] )) 

(Transformation, (Subject, [Delta  :=  Delta  y  o  ], [Evolute  :=  Evolute  y  (Evolute! . Evolute n )  y  o  ] )) 

(Articulation, (Individual, [Intrastice  :=  Intrastice  y  (Intrastice! . Intrasticen  ],(Moiety1  ,Moiety2>. . -n ))) 

(Factorization, ((Cognatei ,Cognate2,...n),[Coenomorph  :=  Coenomorph  y  (Coenomorph! . Coenomorphn)j, Factor)) 

(Consolidation, ((Isolatei, lsolate2,...n), [Interstice  :=  Interstice  y  (Interstice! . Intersticen  )],Combinant )) 

(Involvement, (Type, Intension, Extension)) 

(Capacitation, (Involvement, Means, Yield)) 

(Application, (Involvement,  Device,  Effect)) 

(Instrumentalization, (Involvement, Agency, Solution)) 

(Representation, (Concept, Content, Object)) 

(Designation, (Context,  Designator,  Referent)) 
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“We  shape  our  buildings:  thereafter  they  shape  us.” 

Winston  Churchill,  1962 


4 

RESULTS  PART  II: 

Enterprise  Operating  System  Definition 


After  nearly  a  year  of  planning  and  preparation,  a  program  to  ‘re-invent’  lmas,44  called  the  Lmas 
Enterprise  Architecture  Program  (leap),  was  launched  in  May  of  1999.  The  aim  of  this  program  was 
to  enhance  lmas  competitiveness  by  deploying  a  new  enterprise  operating  system  for  the  company. 
The  specific  objectives  were  to  establish  a  formal  enterprise  Strategy  process;  to  re-design  the  ‘core 
value  stream’  processes  (i.e.,  Product  Realization  and  its  major  subprocesses);  to  integrate  these 
two;  and  to  streamline  their  respective  organizations  and  infrastructure. 

Our  prior  involvement  in  planning  for  this  program,  together  with  our  development  of  a  solution 
to  the  multiple  bom  reconciliation  and  other  related  product  representation  problems,  had 
equipped  us  to  play  a  unique  formalist  role  in  this  activity.  Specifically,  one  major  element  of  the 
leap  approach  involved  pioneering  the  use  of  the  new  formal  methods  and  metasystematics  we  had 
developed  under  mereos  phases  I  and  II  to  design  new  enterprise  processes  for  lmas.  Hence  in 
accordance  with  an  agreement  among  all  principal  mereos  program  stakeholders,  we  were  brought 
into  the  program  as  architects,  and  the  principal  emphasis  of  our  statement  of  work  in  mereos  Phase 
III  was  re-focused  to  accommodate  that  role.4S  Our  specific  mission  was  to  develop  formal  structures 
and  schematic  content  to  frame,  inform,  and  ‘vector’  the  operating  system  design  and  deployment 
activities.  That  is,  we  were  primarily  focused  on  formal  operating  system  requirement  definitions, 
and  on  insuring  that  these  were  rigorous  and  systematic,  complete,  and  traceable  to  stated  leader¬ 
ship  intents— the  attributes  necessary  to  render  formal  definitions  of  use  in  vectoring  and  assessing 
specific  designs.  In  other  words,  most  of  the  functions  we  were  tasked  to  perform  were  analogous 
to  those  performed  by  a  systems  engineering  group  in  a  product  development  program.  Given  that 
the  ‘product’  under  ‘development’  was  an  enterprise  operating  system,  one  might  suggestively  label 
these  as  enterprise  engineering. 


44  Lockheed  Martin  Aeronautical  Systems,  Marietta,  GA. 

45  The  technical  factors  and  strategic  circumstances  that  brought  about  our  involvement  in  leap  were  presented  in  para¬ 
graph  2.6  of  the  Introduction. 
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By  late  1999,  a  corporate  decision  had  been  taken  to  consolidate  the  four  LM  aeronautical  sector 
companies  into  a  single  company  headquartered  at  Ft.  Worth— LM  Aero.  This  decision  rendered 
leap  unnecessary,  and  the  program  was  accordingly  terminated.  However,  the  aim  and  specific 
objectives  of  this  consolidation  were,  for  all  practical  purposes,  the  same  as  those  of  leap,  albeit  in 
a  sector-wide  rather  than  a  single  company  context.  And  although  leap  was  incomplete  when  it  was 
overtaken  by  events,  a  great  deal  of  work  had  been  accomplished,  and  a  great  many  lessons  had 
been  learned.  Because  of  these  two  factors  we  were  asked  to  continue  in  essentially  the  same  for¬ 
malist  capacity  as  before  to  support  the  ‘enterprise  engineering’  activity  of  consolidation  program. 

The  utility  of  formalist  activities,  for  example  those  such  as  ours  in  leap  and  later  in  the  LM  Aero 
consolidation,  and  the  value  of  their  intrinsically  abstract  products  are  notoriously  difficult  to 
clearly  articulate,  especially  to  those  responsible  for  delivering  concrete  results.  Nevertheless,  an 
understanding  the  formalist  role  in  concrete  endeavors  is  important  for  understanding  the  results 
we  present  here. 

It  is  a  practical  matter  of  fact  that  organizations  never  have  the  resources  or  time  required  to 
devise,  let  alone  deploy,  perfect  responses  to  the  challenges  and  opportunities  that  confront  them. 
Cogent  actions  and  effective  products  in  the  real  world  always  embody  constraint-mediated  bal¬ 
ances  between  what  is  possible  in  principle  and  what  is  adequate  in  practice  to  meet  the  needs  at 
hand.  The  essential  role  of  practitioners  is  to  use  their  intuition,  sustained  and  governed  by  their 
experience,  to  strike  such  balances.  That  is,  to  determine  the  most  realistically  attainable  propor¬ 
tions  of  possibility  and  sufficiency  that  is  feasible  given  the  operant  constraints— and,  thereby,  to 
choose  which  actions  will  be  taken  among  the  available  alternatives,  and  to  consequently  shape  the 
solutions  that  will  be  created. 

But  novel,  complex,  and  risk- intensive  endeavors  can  overtax  the  experience  and  intuitive  skills 
of  even  the  most  gifted  of  practitioners.  And  a  program  to  design  and  deploy  a  new  operating  sys¬ 
tem  for  a  major  aerospace  and  defense  contractor  is  most  definitely  a  distinctive,  very  complicated, 
and  risk- laden  endeavor.  The  essential  role  of  formalists  in  such  activities  is  to  provision  practitioners 
with  tools  to  augment  their  intuitive  experienced-based  skills  and  to  inform  the  decisions  they  must 
make  in  these  kinds  of  circumstances.  These  ‘formal  provisions’  invariably  consist  in  at  least  the  fol¬ 
lowing  four  products.  The  first  are  precise  and  complete  characterizations  of  the  challenge  or  oppor¬ 
tunity  at  issue.  The  second  are  delimitations  ascertaining  the  boundaries  of  the  possible  solutions. 
The  third  are  derivations  discerning  the  necessary  elements  of  sufficient  solutions,  and  distinguishing 
these  from  elements  which  are  not.  The  fourth  are  identifications  of  appropriate  effectiveness  criteria, 
both  for  subsequent  actions  and  for  the  decisions  themselves.Taken  together,  these  schematic  tools 
augment  the  clarity,  precision,  and  depth  of  practitioner  understanding;  they  frame  the  threshold 
conditions  of  possible/sufficient  balances;  and,  they  pinpoint  suitable  measures  for  validating  deci¬ 
sions  and  governing  subsequent  actions.  These  tools  do  not  replace  experienced  judgement  or  con¬ 
crete  action.  But  they  can  when  properly  exploited  significantly  enhance  a  practitioner’s  abilities  to 
render  effective  decisions. 

The  value  we  have  consistently  sought  to  deliver  via  our  formal  enterprise  engineering  activities 
should  be  clearer  in  light  of  the  preceding  remarks.  Our  mission  was  to  provision  cognizant  lmas 
and  LM  Aero  practitioners  with  formal  tools  to  facilitate  their  endeavors  to  re-design  their  mecha¬ 
nisms  and  infrastructure  of  enterprise  action.  The  approach  we  adopted  to  accomplish  this  was  to 
design  an  idealized  operating  system  what  we  call  the  New  Aerospace  Enterprise  (nae)  operating 
system,  and  to  iteratively  redact  and  document  crucial  elements  of  that  design,  thereby  providing 
LM  Aero  practitioners  with  useful  definitions  for  their  concrete  purposes  that  were,  nevertheless, 
explicitly  derived  from  and  therefore  traceable  to  what  is  formally  possible. 

The  activities  we  performed  roughly  consisted  in  needs  identification  and  requirements  defini¬ 
tions,  the  latter  encompassing  methodology  development,  formal  systematics,  mission  definition, 
and  schematic  designs  of  enterprise  operating  system  processes.  We  have  organized  our  presenta¬ 
tion  of  the  results  of  those  efforts  along  these  same  lines  and  in  this  order.  Note  that  while  these 
results  complete  the  Mereos  Phase  III  sow,  they  are  interim  products  of  work  in  progress  in  the  larger 
nae  operating  system  definition  context.  We  are  still  actively  engaged  in  that  activity,  and  the 
results  described  here  do  not  represent  the  final  products  of  this  effort. 
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4.1  Enterprise  Operating  System  Needs 

Enterprises  are  intentional  systems  constituting  agencies  for  rendering  solutions  to  requirements  that 
ultimately  originate  from  stakeholder  purposes.  Accordingly,  enterprises  are  intermediate  instrumen¬ 
talities  for  accomplishing  those  aims— the  solutions  they  produce  provision  stakeholder  operations 
for  achieving  them. 

The  primary  challenge  faced  by  every  enterprise  is  to  attain  and  sustain  success.  Success  obtains 
when  results  of  enterprise  actions  are  instrumental  solutions  for  operations  that  accomplish  stake¬ 
holder  purposes.  That  is,  success  obtains  when  there  is  effective  instrumentalization  and  applica¬ 
tion.46  Success  endures  when  effective  instrumentalization  and  application  are  consistently 
repeatable— i.e.,  reliably  effective.  Thus,  at  first  glance,  success  hinges  on  creating  and  maintaining 
alignments  between  stakeholder  purposes  and  enterprise  capabilities  to  realize  solutions  to  the 
intents,  needs,  and  requirements  deriving  from  those  purposes. 

Enterprise  capabilities  subsist  in  the  capabilities  of  enterprise  operating  systems— instrumentalities  for 
purposeful  collective  action.  These  are  integrated  ‘socio-technicaT  systems  comprising  the  pro¬ 
cesses,  organizations,  policies,  and  infrastructure  (facilities,  methods  and  techniques,  information 
systems,  etc.)  that  provision  enterprises  to  act— to  realize  solutions  that  in  turn  provision  accom¬ 
plishment  of  stakeholder  purposes.  The  inputs  to  an  enterprise  operating  system  are  leadership 
intents  and  objectives  that  define  and  prioritize  stakeholder  purposes.  Its  outputs  are  solutions  to  the 
needs  and  requirements  pertaining  to  those  purposes.  Its  means  of  producing  those  solutions  are 
enterprise  processes.  Thus  success  ultimately  hinges  on  creating  and  maintaining  parity  between 
action  program  requirements  deriving  from  enterprise  objectives  on  the  one  hand,  and  enterprise 
operating  system  capabilities  to  execute  those  programs  and  thereby  satisfy  those  requirements  on 
the  other. 

Achieving  and  sustaining  this  balance  is  exacting  in  stable  environments  and  extremely  difficult 
in  volatile  ones,  and  business  environments  are  more  fluid  today  than  ever.  Moreover,  increasingly 
intense  competitive  pressures  driven  by  factors  such  as  globalization  have  compressed  the  time 
enterprises  have  to  respond  to  change.  Enterprises  in  every  business  domain  need  operating  systems 
that  both  assure  consistent  performance  and  rapidly  adjust  to  change  in  order  to  succeed  and  remain 
competitive. 

The  end  of  the  Cold  War  initiated  sweeping  changes  in  the  defense  industry.  Two  of  note  were 
dramatic  reductions  in  the  number  and  scale  of  weapon  system  acquisition  programs  and  its  conse¬ 
quents:  drastic  diminution  of  the  business  base,  collateral  downsizing  and  subsequent  consolida¬ 
tion  of  the  defense  industrial  base,  and  intensification  of  competition  for  what  business 
opportunities  remain.  Two  superficially  opposed  trends  sparked  by  these  changes  and  by  globaliza¬ 
tion  have  also  emerged.  The  first  is  the  increasing  tendency  of  governments  to  vigorously  protect 
their  defense  industrial  infrastructures  from  extra-national  competition  and  to  sustain  their  capa¬ 
bilities  in  the  face  of  decreasingly  frequent  opportunities  to  exercise  them.  The  second  is  a  marked 
increase  in  collaboration  among  defense  contractors,  both  within  and  across  national  boundaries, 
to  pool  scarce  resources  and  to  exploit  complementary  capabilities  and  congruent  interests.  In  the 
case  of  the  Joint  Strike  Fighter  (jsf)  program,  this  cooperation  has  extended  beyond  collaboration 
among  contractors  of  different  nations  to  include  the  governments  of  the  nations  themselves.  Thus 
sustaining  competitiveness  in  this  new  aerospace  and  defense  environment  entails  new  enterprise 
operating  system  capabilities  to  meet  new  needs,  over  and  above  basic  effectiveness,  reliability,  and 
agility.  A  sketch  of  the  four  most  significant  of  these  from  an  operating  system  design  perspective 
follows. 

4.1.1  Greater  Product  Realization  Amplitude 

One  major  consequence  of  globalization  is  that  stakeholder  populations  are  both  much  larger  and 
more  diverse  in  their  aims  than  ever  before.  The  elements  constituting  defense  program  stakeholder 
value  are  correspondingly  more  complex  and  multifaceted.  Technical  superiority  is  not  the  domi¬ 
nating  determinant  of  value  it  once  was.  Complex  and  abstract  strategic  factors,  such  as  infrastruc- 


46  An  overly  technical  way  of  saying  that  enterprises  succeed  when  their  stakeholders  do. 
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ture  capability  retention  and  economic  asset  multiplication,  increasingly  represent  major 
constituents  of  value,  and  the  processes  of  determining  and  delivering  these  involves  correspond¬ 
ingly  more  comprehensive  enterprise  operating  system  processes. 

This  in  turn  entails  a  major  architectural  change  in  the  relationship  of  stakeholder  value  to  the  Prod¬ 
uct  Realization  process.  Specifically,  the  long-standing  conception  of  Product  Realization  as  the 
principal  and  dominant  enterprise  mechanism  for  delivering  value  is  simply  too  narrow  to  encom¬ 
pass  the  realities  of  the  new  defense  environment.  Consider:  the  principal  components  of  solutions 
rendered  by  Cold  War  programs  were  technical  systems.  That  is,  if  one  envisions  the  total  solution  as 
a  cube,  and  that  element  of  the  solution  produced  by  these  programs  as  another  cube,  nested  inside 
the  first  one,  the  two  were  typically  almost  the  same  size.  Hence  the  total  solution  and  the  techni¬ 
cal  solution  were,  for  all  practical  purposes,  co-extensive,  and  technical  factors  were  the  primary 
determinants  of  value.  However,  this  is  simply  no  longer  true;  the  technical  jsf  solution  for  example 
constitutes  a  much  smaller  portion  of  the  total  jsf  solution  than  did  those  of  any  prior  program. 
Success  accordingly  necessitates  a  greater  parity  between  the  strategic  and  technical  axes  of  aero¬ 
space  and  defense  enterprises.  Determining  all  the  attributes  constituting  stakeholder  value— not 
just  the  technical  attributes— is  a  critical  enabler  of  attaining  this  parity.  Delivering  that  total  value 
entails  a  process  with  a  greater  amplitude  than  classical  Product  Realization:  it  requires  a  suitably 
capable  Solution  Realization  process. 

4.1.2  Process  Multi-Modality 

One  major  consequence  of  the  drastic  diminishment  of  the  aerospace  and  defense  business  base  is 
that  far  fewer  business  opportunities  exist  in  traditional  markets,  making  capture  of  these  a  matter 
of  survival  and  pursuit  of  new  opportunities  outside  of  these  markets  essential  for  sustainable 
growth.  Two  readily  accessible  opportunities  for  growth  are  commercial  applications  of  advanced 
technology  and  complete  logistical  support  of  their  own  systems  and  those  of  others.  The  former 
represents  a  means  to  exploit  their  vigorous  innovation  streams;  the  latter  a  means  to  exploit  their 
prodigious  manufacturing  capabilities.  The  strategic  and  technical  ‘spin-back’  potentials  of  both 
would  convey  significant  benefits  to  the  core  business  as  well. 

However,  these  and  any  other  significant  opportunities  for  aerospace  and  defense  enterprises  are 
situated  in  business  environments  that  differ  substantially  from  their  traditional  venues.  Dominated 
by  market-driven  commercially-oriented  business  models,  the  structures  and  modalities  of  these 
environments  are  essentially  foreign  to  classical  defense  contractor  enterprises.  That  is,  the 
requirements -driven  engineering-oriented  business  model  of  classical  aerospace  and  defense  enter¬ 
prises  reflects  the  modalities  of  their  core  businesses.  Their  operating  systems— specifically  their 
constituent  enterprise  processes— evolved  within  these  lines  and  would  not,  accordingly  enable 
defense  contractors  to  function  competitively  in  purely  commercial  environments. 

A  diversification  technique  called  divisionalization  is  frequently  employed  to  effect  entry  into  new 
markets  while  protecting  existing  positions  in  traditional  core  businesses.  This  typically  involves 
creating  a  new  semi-autonomous  ‘strategic  business  unit’  (sbu)  in  one  form  or  another.  Divisional¬ 
ization  can  constitute  an  optimal  solution  to  a  variety  of  strategic  and  operational  problems,  and  is, 
in  some  cases,  the  only  possible  solution  given  regulatory  constraints.  Nevertheless,  from  a  formal 
enterprise  engineering  perspective,  divisionalization  is  articulation,  to  invoke  the  relation  of  that 
name  defined  in  Section  3,  and  this  solution  to  business  model  heterogeneity  is  not  the  only  one 
available.  Subsumption— i.e.,  enterprise  process  generalization  or  multi-modality— is  another  solution. 
Cogently  designed  enterprise  processes  capable  of  executing  multiple  business  models  (or  substan¬ 
tively  divergent  variants  of  a  single  model)  can,  in  the  right  circumstances,  yield  the  same  perfor¬ 
mance  and  effectiveness  gains  as  articulating  or  creating  distinct  processes,  without  the 
consequential  duplication,  integration  problems,  and  loss  of  commonality. 

4.1.3  Action  Multilaterality 

There  are  two  fundamental  ways  an  enterprise  can  execute  a  process.  The  first  is  unilaterally— the 
enterprise  acts  alone  or  at  least  is  the  dominant  execution  and  governance  agency  of  the  process. 
The  second  is  multilaterally— the  enterprise  acts  in  concert  with  others.  Unilateral  action  is  effi- 
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cient  but  requires  total  command  of  all  the  resources  and  capabilities  to  execute  and  govern  a  pro¬ 
cess.  Multilateral  action  is  less  efficient  because  it  requires  coordination.  However  multilateral 
action  does  not  require  total  command  of  all  the  resources  and  capabilities  to  execute  a  process;  it 
is  a  strategy  to  accomplish  stakeholder  purposes  with  less. 

The  intensely  competitive  and  global  business  environment  places  severe  constraints  on  the 
resources  available  to  an  enterprise  to  achieve  and  sustain  success.  Protecting  core  market  share 
requires  sustaining  an  adequate  business  capture  rate.  Penetrating  new  markets  requires  balancing 
investment  with  risk.  The  capability  to  act  in  multilateral  partnerships  with  customers,  suppliers, 
and  competitors  is  the  most  effective  means  available  to  achieve  both  of  these  objectives  in  the  cur¬ 
rent  business  environment. 

4.1.4  Totality  and  Autonomism 

Toyota  launched  their  “Toyota  Production  System”  (tps)  initiative  in  the  1950's  to  integrate  pro¬ 
cesses,  people  skills,  technology  and  information  across  a  core  element  of  their  enterprise— the  fac¬ 
tory  floor.  Their  purpose  was  to  create  a  product  realization  system;  an  operating  system  focused  on 
manufacturing  and  assembly  of  Toyota  products.  More  recently,  many  other  organizations  have  pur¬ 
sued  similar  but  broader  initiatives  to  design  and  deploy  enterprise-wide  operating  systems.  Nota¬ 
ble  private  sector  examples  are  those  of  Chrysler  and  Alcoa;  the  Acquisition  Reform  initiative  of  the 
U.S.  Department  of  Defense  is  an  illustrative  public  sector  example. 

These  recent  initiatives  are  incremental  steps  towards  satisfying  the  need  for  all-inclusive  high- 
performance  enterprise  operating  systems.  Each  has  yielded  compelling  tactical  benefits  and  clear 
strategic  advantages.  Collectively  they  also  exemplify  two  limitations,  albeit  to  varying  degrees.  The 
first  is  partiality.  No  existing  operating  system  in  fact  fully  encompasses  its  respective  enterprise; 
each  is  incomplete  to  some  extent.  All  tend  to  reflect  an  emphasis  on  one  or  more  areas  of  applica¬ 
tion  over  others;  each  is  suboptimal  in  some  respect.  Thus  despite  the  very  real  value  delivery 
improvements  these  initiatives  demonstrate,  the  enterprise  operating  systems  produced  by  them 
are,  nevertheless,  partial  rather  than  total  solutions. 

Existing  operating  systems  require  exceptional  expertise  to  sustain  and  prodigious  efforts  and 
expense  to  modify  them— they  are  fragile.  The  fluidity  of  current  business  environments  coupled 
with  the  fragility  of  existing  operating  systems  entails  more  effective  mechanisms  for  change. 
Enterprise  operating  systems  are  products  of  a  process  we  call  Enterprise  Realization,  and  changing 
them  involves  an  iterative  execution  of  this  process,  in  situ.  This  process  is  outside  the  scope  of 
existing  operating  system  capabilities  to  execute  directly;  that  is,  Enterprise  Realization  is  not  a  pro¬ 
cess  of  existing  enterprise  operating  systems.  Enhancing  the  effectiveness  of  enterprise  change 
entails  embedding  this  process  into  operating  systems— i.e.,  devolving  the  task  to  changing  an  oper¬ 
ating  system  to  the  operating  system  itself. 


59 


4.2  Enterprise  Operating  System  Requirements 

For  presentational  purposes  we  have  divided  the  requirements  entailed  by  the  four  enterprise  oper¬ 
ating  system  needs  outlined  in  paragraph  4.1  into  three  distinct  groups— methodological  require¬ 
ments,  metastructures,  and  design  requirements.  The  latter  have  been  further  subdivided  into 
mission  definition  and  enterprise  process  requirements. 

The  requirements  presented  here  reflect  our  focus  on  systematic  issues  during  Mereos  Phase  III 
and  our  formalist  role  in  leap  and  the  subsequent  LM  Aero  consolidation  program.  These  should 
not,  therefore  be  construed  in  any  way  as  constituting  a  complete  requirements  specification  for  an 
enterprise  operating  system  satisfying  the  needs  articulated  above.  As  we  stated  earlier,  the  nae 
operating  system  design  project  is  a  work  in  progress  continuing  under  other  auspices.  What  fol¬ 
lows  describes  requirements  that  were  defined  by  the  end  of  the  mereos  program. 

4.2.1  Methodological  Requirements 

The  shortcomings  exemplified  by  existing  operating  systems  together  with  the  needs  identified  in 
paragraph  4.1  are  conjunctively  symptomatic  of  a  methodological  gap.  All  prior  operating  system  real¬ 
ization  initiatives  have  been  based  on  relatively  informal  processes  that  rely  heavily  on  organiza¬ 
tional  experience  and  best  practices  in  combination  with  methods  and  technology  such  as  those 
mentioned  above.  But  the  need  to  increase  scope  and  effectiveness  of  these  initiatives  will  generate 
concomitant  stresses  on  the  realization  processes— particularly  on  underlying  methods.  Existing 
methods  are  simply  incapable  of  producing  total  enterprise  operating  system  solutions  at  the  requi¬ 
site  levels  of  scale,  performance,  and  sustainability;  the  incompleteness,  suboptimality,  and  fragility 
of  systems  produced  by  these  methods  are  the  results.  This  methodological  gap  is  reminiscent  of  the 
one  that  afflicted  the  early  years  of  the  space  program.  The  family  of  methods  now  collectively 
known  as  Systems  Engineering  were  developed  to  fill  that  gap.  An  analogous  discipline,  which  we 
call  enterprise  engineering,  is  emerging  to  fill  this  one. 

Enterprise  engineering  is  an  embryonic  interdisciplinary  field  concerned  with  design,  deploy¬ 
ment,  and  sustainment  of  enterprise  operating  systems.  Enterprise  engineering  accordingly  com¬ 
prises  formal  processes,  methods,  and  techniques  for  producing  and  sustaining  these  systems. 

Enterprise  engineering  is  a  new  synthesis  of  several  existing  disciplines.  The  dominant  two  of 
these  are  systematics  and  systems  engineering.  At  first  glance,  enterprise  engineering  bears  a  strong 
resemblance  to  the  latter.  Like  that  discipline,  it  is  formal;  many  of  its  central  methods  are  (suitably 
modified)  systems  engineering  methods;  and,  it  has  also  emerged  in  response  to  a  need  arising  from 
unique  historical  circumstances.  However,  one  can  be  easily  misled  by  this  resemblance,  as  is  illus¬ 
trated  quite  nicely  by  a  quote  from  a  recent  article  in  Aviation  Week: 

“This  industry  [A&  D]  invented  systems  engineering,  but  traditionally  it  has  been  applied  to  only  half  of 
the  business.  If  companies  applied  the  same  expertise  to  work,  products  would  cost  a  lot  less,  quality 
would  be  substantially  better,  and  products  would  reach  the  consumer  much  faster."  [6]  (Italics  ours) 

The  fundamental  idea  expressed  above  is  of  course  entirely  sound.  Who  could  rationally  argue 
against  the  benefits  of  bringing  systems  engineering  rigor,  traceability,  and  balance  to  the  task  of 
designing  ‘work’— i.e.,  enterprise  processes?  However  the  implicit  premise  that  ‘work’  is  the  same 
kind  of  thing  as  ‘product/  and,  therefore,  that  designing  either  of  these  is  just  a  systems  engineering 
job  is  naive.  It  is  also  false.  The  LM  Aero  enterprise  operating  system  (to  invoke  an  example)  is  not 
the  same  kind  of  thing  as  the  air  vehicle  systems  it  produces.  Specifically,  it  is  more  complex,  more 
abstract  than  any  product  system  it  produces,  and  it  comprises  intentional  elements  in  ways  distinct 
from  those  of  any  other  existing  system. 

1.  Complexity 

One  signature  characteristic  that  distinguishes  enterprises  and  their  operating  systems  from 
any  other  artifact  producible  by  current  technics  is  that  they  are  more  complex  than  the  solu¬ 
tions  they  produce.47  And,  they  are  more  complex  in  three  distinct  ways:  they  are  taxonom- 
ically,  integrally,  and  frequently  numerically  more  complex  than  any  of  their  offerings. 
Consider  LM  Aero  and  its  operating  system  on  the  one  hand  and  the  F-22  on  the  other  as 
examples.  Clearly  there  is  a  much  larger  range  of  taxonomic  variation— differences  in 
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kind— among  the  elements  constituting  LM  Aero  than  those  constituting  the  F-22.  More¬ 
over,  the  degree  of  intricacy— the  number  of  interfaces  between  and  relations  among  ele¬ 
ments— of  LM  Aero  far  surpasses  those  between  elements  of  the  F-22.  And  finally,  at  least  in 
this  specific  example,  the  sheer  number  of  LM  Aero  elements  far  exceeds  that  of  the  F-22. 

2.  Abstraction 

A  second  characteristic  distinguishing  enterprises  and  their  operating  systems  from  any 
other  artifact  producible  by  current  technics  is  that  they  are  more  abstract  than  the  solutions 
they  produce.48  And,  they  are  more  abstract  in  two  distinct  ways:  they  are  quantitatively  and 
qualitatively  more  abstract  than  any  of  their  offerings.  Consider  again  LM  Aero  and  the  F-22. 
Both  the  functional  and  physical  architectures  of  LM  Aero  encompass  a  far  larger  quantity 
of  abstract  entities  than  do  those  of  the  F-22.  Moreover,  significant  numbers  of  these 
abstract  elements  are  of  a  much  higher  rank,  or  ‘distance’  from  the  concrete  world,  than 
are  any  of  those  constituting  the  functional  and  physical  architectures  of  the  F-22. 

3.  Intentionality 

A  third  and  perhaps  the  most  far-reaching  characteristic  differentiating  enterprises  and 
their  operating  systems  from  any  other  artifact  producible  by  current  technics  is  that  enter¬ 
prises  are  literally  intentional  or  conscious  beings,  and  enterprise  operating  systems  comprise 
intentional  beings  to  a  far  greater  extent  and  depend  on  them  to  a  greater  degree  than  any 
enterprise  offering.49  The  vast  majority  of  extant  legal  systems  treat  businesses  and  as  well 
as  types  of  enterprises  as  individuals— as  members  of  their  respective  societies,  and  like  any 
other  individual,  these  legal  systems  entitle  them  with  certain  rights  and  charge  them  with 
certain  responsibilities  within  those  societies.  Enterprises  such  as  LM  Aero,  like  any  other 
intentional  beings,  sustain  intentional  states,  are  autopoietic,  autonomous,  and  auto-onto- 
genetic.  No  artifact  producible  by  current  technics  exemplifies  any  one  of  these  characters, 
let  alone  all  three  of  them  conjunctively. 

These  quantitative  and  qualitative  differences  in  complexity,  abstraction,  and  intentional  consti¬ 
tution  distinguishing  enterprises  and  their  operating  systems  from  the  products  they  produce  have 
far-reaching  methodological  consequences.  The  constellation  of  issues  pertaining  to  scale,  intri¬ 
cacy,  and  formal  and  intentional  structures  as  subjects  in  their  own  rights  take  on  a  much  larger  and 
much  more  critical  role  in  an  enterprise  engineering  context  than  they  do  in  classical  systems  engi¬ 
neering.  Simplistically  speaking,  airplanes  don’t  design,  build,  and  support  airplanes,  nor  do  they 
develop  and  execute  strategies,  nor  do  they  upgrade  themselves— but  enterprise  operating  systems 
are  intentional  constructs  that  must  do  all  of  these  things  and  more.  While  systems  engineering 
methods  are  capable  of  meeting  the  difficulties  arising  from  greater  complexity,  albeit  not  without 
some  degree  of  stress,  they  are  not  capable  of  satisfying  other  unique  methodological  requirements 
for  successful  operating  systems  design. 

Thus  enterprise  engineering  cannot  be  just  a  variant  or  application  of  systems  engineering.  It  must 
instead  constitute  a  new  synthesis  disciplines  comprising  the  requisite  unifying  principles  and  tech¬ 
niques  as  an  integral  gestalt.  These  are: 

1.  Systematics:  the  science  of  diversity  [18.1],  concerned  with  the  formal  structures  of  varia¬ 
tion,  taxonomy,  and  classification,  which  provides  the  integrating  metastructures  and  con- 


47  Of  course  one  of  the  principal  aims  of  advancing  the  engineering  and  manufacturing  arts— specifically  automation— is 
to  ‘invert’  this,  thereby  enabling  simple  enterprises  to  render  extraordinarily  complex  solutions.  The  one-person  cnc 
machining  job  shop  is  a  good  example  of  this. 

48  One  can  characterize  many  of  the  advances  in  the  engineering  and  manufacturing  arts  as  aiming  to  invert  this  also— 
to  enable  creation  of  increasingly  more  abstract  artifacts,  thereby  offering  greater  capability  with  commensurate 
decreases  in  requisite  instrumentality,  or  entirely  new,  previously  unrealizable  capabilities.  Software  and  electronic 
computing  machines  (versus  mechanical  ones)  are  examples  of  the  former;  genetic  engineering  is  an  example  of  the 
latter. 

49  The  enterprise  of  so-called  Artificial  Intelligence  seeks  to  eliminate  this  distinction  by  creating  conscious  artifacts, 
but  despite  the  claims  of  some  of  its  market- driven  proponents,  this  has  yet  to  be  achieved. 
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ceptual  framework  for  enterprise  engineering. 

2.  Systems  Engineering:  the  discipline  concerned  with  design  of  life-cycle  balanced  systems, 
which  performs  the  analogous  role  in  enterprise  engineering  of  enterprise  operating  sys¬ 
tems  design. 

3.  Strategic  Management:  the  discipline  concerned  with  action  program  definition  and  gover¬ 
nance,  which  in  enterprise  engineering  provides,  via  its  methods,  techniques  for  stake¬ 
holder  intent  definition  and  enterprise  capability  analysis,  and  because  of  its  subject 
domain,  a  source  for  strategy  process  design. 

4.  Informatics:  the  discipline  concerned  with  design  and  development  of  effective  (comput¬ 
able)  representation  systems,  which  is  used  pervasively  in  enterprise  engineering  both  as  a 
basis  for  information  systems  design  and  for  enterprise  engineering  automation. 

5.  Ontology:  the  “science  of  Being;”  the  discipline  that,  in  conjunction  with  a  suitably 
informed  phenomenology,  is  concerned  with  the  forms  of  form  and  intentionality.  Its  role 
in  enterprise  engineering  is  analogous  to  the  role  of  mathematics  in  the  natural  sciences;  it 
provides  the  methods  and  techniques  for  the  analysis  of  abstractions— i.e.,  pure  formal 
structure. 

Thus  enterprise  engineering  is  a  new  discipline,  albeit  in  a  synthetic  sense  rather  than  an  analytic 
one,  and  it  is,  accordingly,  something  over  and  above  the  mere  sum  of  its  elements.  There  are  nev¬ 
ertheless  functional  and  historical  analogies  between  enterprise  engineering  and  systems  engineer¬ 
ing  that,  when  articulated,  serve  to  illuminate  the  crucial  role  enterprise  engineering  will  play  in 
advancing  business  design,  execution  and  management.  Unfortunately  this  topic  is  outside  the 
scope  of  our  discussion  here.  What  we  can  say  is  that  systems  engineering  evolved  to  address  a 
methodological  gap,  which  was  the  root  cause  of  several  technical  failures  suffered  by  the  American 
space  program  in  its  early  days.  Enterprise  engineering  is  emerging  to  address  an  analogous  but  dis¬ 
tinct  methodological  gap,  which  is  the  root  cause  of  the  shortcomings  of  current  enterprise  operat¬ 
ing  systems.  These  limit  operating  system  capabilities  to  consistently  deliver  superior  value  and 
effectively  respond  to  change— the  two  essential  ingredients  of  strategic  success. 
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4.2.2  Metastructure 
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Table  7.  Enterprise  Operating  System  Definition  Metastructures 


Enterprise  operating  systems  are  products  of  the  Enterprise  Realization  process,  a  variant  of  the 
Product  Realization  process.  We  pointed  out  the  analogies  between  these  two  processes  and  their 
respective  products  elsewhere,  and  will  not  repeat  that  discussion  here.  What  we  have  not  previ¬ 
ously  defined  are  the  structural  requirements  for  producing  adequate  definitions  of  enterprise  operating 
systems,  their  elements,  and  the  relations  between  these. 

To  gain  an  insight  into  the  purpose  of  these  requirements  in  the  context  of  operating  system  def¬ 
initions,  consider  the  analogous  relationship  between  the  structures  defined  by  ansi  y  14.5  (“Geo¬ 
metric  Dimensioning  and  Tolerancing”)  and  feature  definitions  of  mechanical  product  system  parts. 
This  specification  describes  requirements  for  defining  maximally  interchangeable  parts.  It  accomplishes 
this  by  prescribing  how  both  the  positional  and  geometric  characteristics  are  to  be  defined,  and 
how  allowable  positional  and  geometric  tolerances  for  these  characteristics  are  to  be  defined.  The 
metastructures  represent  an  analogous  mechanism  for  defining  maximally  rigorous  and  complete  operat¬ 
ing  system  elements.  This  is  accomplished  by  prescribing  w hat  structures  such  definitions  must 
define,  how  these  are  to  be  specified,  conditions  for  their  use,  and  finally,  the  mechanism  for  defining 
new  derivative  structures  from  the  fundamental  ones.  Thus  the  22  specific  relation  types  depicted 
above  in  Table  7  collectively  constitute  the  necessary  and  sufficient  metastructures  for  defining 
enterprise  operating  systems  and  their  elements  satisfying  the  four  enterprise  operating  system 
needs  previously  outlined  in  paragraph  4.1.  That  is,  definitions  of  any  enterprise  operating  system 
solutions  to  those  needs  must  be  explicitly  framed  in  terms  of  these  22  structures. 

The  reader  will  no  doubt  note  that  the  first  17  of  these  structures  are  the  same  as  those  enumer¬ 
ated  in  Table  1  on  page  37  in  Section  3  of  this  document.  The  only  differences  between  the  two 
tables  are  the  examples  presented  to  illustrate  their  applications.  This  coincidence  is  not  accidental: 
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enterprise  operating  systems  are  products  in  every  sense  of  that  term,  although  as  we  pointed  out 
earlier,  they  differ  from  more  familiar  product  systems  in  complexity,  abstractness,  and  intentional 
constitution.  Because  operating  systems  are  products,  there  is  no  reason  to  suppose  that  the  met¬ 
aschematic  requirements  for  their  definitions  would  differ  from  those  for  any  other  complex  product 
system  definition,  excepting  of  course  those  requirements  deriving  from  the  aforementioned  dif¬ 
ferences  individuating  operating  systems  from  other  types  of  systems.  And,  in  fact,  almost  all  of 
these  metaschematic  requirements  are  the  same.  Hence  most  operating  system  metastructure 
requirements  have  already  been  defined  in  paragraph  3.2.1  of  Section  3;  these  are  incorporated 
herein  by  reference. 

The  remaining  5  relation  types  listed  in  Table  7  collectively  constitute  the  metataxonomic  struc¬ 
tures  required  to  define  enterprise  operating  system  elements  and  attributes  that  are  not  found  in 
typical  product  systems— that  is,  those  which  are  unique  to  these  types  of  systems.  These  structures 
are  extraordinarily  abstract,  and  would  require  an  extensive  introductory  presentation  followed  by 
a  very  lengthy  discussion  to  adequately  describe  them.  As  we  do  not  explicitly  invoke  or  refer  to 
any  of  these  structures  in  this  document,  we  elected  to  not  to  define  these  here.s° 

4.2.3  Mission  Definition 

Mission  statements  articulate  the  primary  and  invariant  purposes  of  enterprises— they  define  w hat  is 
to  be  accomplished,  independently  of  circumstantial  specifics.  Strategies  delineate  programs  for 
achieving  these  and  other  consonant  but  more  particular  aims— they  define  how  missions  are  to  be 
achieved.  Enterprise  operating  systems  are  instrumentalities  for  purposeful  collective  action— they 
comprise  the  mechanisms  for  executing  these  programs.  Mission  statements  are,  accordingly,  critical 
for  both  rational  strategy  development  and  systematic  operating  system  design.  They  constitute  the 
ultimate  grounds  for  action,  the  ultimate  criteria  for  evaluating  results,  and  the  ultimate  source  of 
design  requirements. 

Mission  definition  requirements  in  an  enterprise  engineering  context  differ  from  those  in  famil¬ 
iar  strategic  management  contexts.  In  the  latter  they  articulate  primary  organizational  imperatives 
to  a  human  audience,  and  should,  accordingly,  exemplify  the  attributes  appropriate  to  that  purpose. 
From  an  enterprise  engineering  perspective,  mission  statements  are  enterprise  operating  system 
needs  statements ,  and  must,  therefore,  be  designed  with  that  purpose  in  mind.  The  following  quotation 
below  will  help  illustrate  this  point  more  clearly. 

“The  'mission'  of  a  company  is  an  important  element  in  establishing  the  strategy  of  the  organization. 
Establishing  the  mission  itself  is  usually  a  difficult  and  demanding  task.  Top  management  tends  to  ago¬ 
nize  for  long  periods  of  time  over  the  development  of  a  mission  statement:  the  process  involves  negoti¬ 
ation  and  compromise,  but  is  usually  leadership  led—  and  depends  upon  critical  input  from  the  ceo. 
Surprisingly,  perhaps,  despite  all  the  effort  expended,  many  mission  statements  tend  to  seem  full  of  plat¬ 
itudes  and  motherhood  statements. 

...  M  ission  statements  need  to  be  communicated  throughout  the  organization.... 

Good  mission  statements  tend  to  besimpleand  easy  to  understand  at  all  levelsof  the  organization.... 

For  example,  in  the U S  G eneral  Electric  Company,  themission  for  each  businessisto  'benumber  one 
or  two  in  the  world  or  sell  it,  closeit,  or  fix  it.'  Such  astatement  is  readily  understood  and  memorable." 

[4.1] 

Based  on  these  statements,  we  can  frame  a  thesis  defining  the  requisite  attribute  of  a  mission  defi¬ 
nition  in  a  strategic  management  context: 

Good  mission  statements  consist  in  transparent  expressions  of  strategic  intent. 

By  “transparent”,  we  mean  symbolic.  That  is,  statements  which  are  sufficiently  evocative— allusive  and 
mnemonic— to  engender  universal  understanding  of  the  aims  these  statements  express,  and  to  pro- 

50  Excepting  correlation,  these  structures  are  the  principal  structures  underpinning  the  discipline  of  systematics  and 
are,  accordingly,  described  by  that  body  of  literature.  Although  now  out  of  print  and  therefore  somewhat  difficult  to 
find,  we  would  highly  recommend  that  anyone  interested  in  this  topic  acquire  a  copy  of  Principles  of  Systematic  Zoology 
[18]  and  study  it. 
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mote  operable  concurrence  among  various  interests  concerning  those  aims.  In  a  word,  statements 
that  impel  focus. 

Although  memorability  and  evocativeness  are  useful  attributes  in  an  enterprise  engineering  con¬ 
text,  something  else  is  required,  which  we  state  as  a  another  thesis: 

Good  mission  statements  consist  in  effective  expressions  of  strategic  intent. 

By  "effective,”  we  mean  actionable.  That  is,  statements  which  are  sufficiently  definitive— specific  and 
precise— to  enable  systematic  development  of  operating  systems  capable  of  executing  the  action 
programs  required  to  achieve  the  aims  these  statements  express,  and  to  facilitate  cogent  selection  of 
measures  of  effectiveness  for  evaluating  both  designs  for  these  systems  and  outcomes  of  their 
actions.  In  a  nutshell,  statements  that  sustain  operational  traceability. 

Producing  an  effective  mission  definition  instance  presupposes  a  suitable  definition  of  the  mission 
taxon  itself.  Figure  18  graphically  depicts  the  definition  of  this  taxon  we  developed  during  Mereos 
Phase  III,  and  a  brief  description  of  its  elements  follows. 
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Figure  18.  Mission  Definition  Elements 
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I  Delimitation 

The  four  major  elements  constituting  the  delimitation  element  of  the  mission  taxon  collectively 
define  the  situating  environment  of  its  strategic  intentions  including  the  agencies  that  sustain  those 
intentions,  thereby  determining  the  boundaries  of  permissible  action  for  achieving  that  mission. 

Authentication 

The  authentication  element  of  the  mission  taxon  identifies  the  agency  authorizing  the  enterprise  to 
undertake  that  mission. 

Constitution 

Not  all  actions  in  pursuit  of  a  mission  are  permissible.  There  are  constraints  on  what  actions  the 
enterprise  can  take  to  achieve  its  mission.  These  constraints  are  expressed  as  ‘value’  statements  or 
fundamental  tenets ,  and  are  embodied  by  core  values  that  govern  the  actions  of  the  enterprise  and  its 
stakeholders.  The  constitution  element  of  the  mission  taxon  defines  these  fundamental  tenets  that 
guide  the  actions  of  the  stakeholders  in  the  enterprise.  These  tenets  represent  the  sources  from 
which  the  nomological  elements  of  the  assurance  element  are  derived. 

Stakeholders 

The  stakeholders  element  of  the  mission  taxon  identifies  those  agencies  possessing  interests  in  the 
enterprise.  These  agencies  comprise  individuals,  corporate  entities,  governments,  and  societies 
whose  strategic  purposes  actually  or  potentially  entail  the  enterprise  as  an  instrumentality  for 
accomplishing  those  purposes.  Business  enterprises  typically  comprise  9  primary  stakeholder 
groups,  as  enumerated  below. 

1.  Customers 

Customers  are  agencies  that  receive  goods  and  services  from  an  enterprise  in  return  for  an 
agreed  upon  valuation  in  some  medium  of  exchange. 

2.  Employees 

Employees  are  individuals  that  receive  regular  compensation  from  an  enterprise  in 
exchange  for  regular  performance  of  assigned  tasks.  Management  is  a  variant  of  employee. 

3.  Superiors 

Superiors  are  agencies  that  authoritatively  define  superordinate  intent  and  effectiveness 
measures  to  which  all  enterprise  intent  and  assurance  is  subordinate,  and  which  cede  enti¬ 
tlements  to  provision  an  enterprise  to  execute  that  intent. 

4.  Stockholders 

Stockholders  are  agencies  that  own  or  hold  one  or  more  shares  in  an  enterprise. 

5.  Suppliers 

Suppliers  are  agencies  that  furnish  goods  and  services  to  an  enterprise  in  return  for  an 
agreed  upon  valuation  in  some  medium  of  exchange. 

6.  Unions 

Unions  are  agencies  consisting  of  employees  of  one  or  more  agencies  that  share  common 
interests  and  act  collectively  to  influence  employment  policies  and  practices. 

7.  Peers 

Peers  are  agencies  satisfying  one  of  the  following  two  conditions. 

0.1.  A  peer  is  an  agency  that  shares  an  enterprise’s  superiors,  is  of  equal  or  analogous 
rank  to  an  enterprise  in  superordinate  context,  and  thus  is  an  executor  of  the  same 
superordinate  intent  as  that  enterprise. 
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0.2.  A  peer  is  an  agency  that  does  not  share  an  enterprise’s  superiors,  shares  at  least  one 
strategic  or  tactical  intent  with  that  enterprise,  and  has  explicitly  agreed  to  pool 
resources,  coordinate  actions,  and  share  the  products  and  effects  resulting  from 
those  actions  in  pursuit  of  that  intent.  These  latter  are  partners. 

8.  Communities 

Communities  are  agencies  consisting  of  individuals  acknowledging  a  unity  of  purpose, 
common  interests,  or  common  culture. 

9.  Competitors 

Competitors  are  agencies  offering  similar  or  equivalent  products  and  services  in  the  same 
markets  as  those  offered  by  an  enterprise,  who  are  engaged  in  executing  similar  or  identical 
intent,  and  who  are  not  peers  or  superiors  of  that  enterprise. 

Effectivity 

The  effectivity  element  of  the  mission  taxon  delineates  the  conditions  under  which  a  mission  is 
operant  for  an  enterprise. 

I  Mission  Intent 

The  central  elements  of  the  mission  taxon  are  statements  of  strategic  intent.  Definitive  characteriza¬ 
tions  of  strategic  intents  consists  in  rigorous  definitions  of  their  elements  and  the  elements  of  their 
situating  contexts,  produced  via  the  Intent  Formalization  process  described  in  paragraph  4. 2. 4. 2 
below. 

I  Mission  Assurance 

The  two  major  elements  constituting  the  assurance  of  the  mission  taxon  delineate  measures  for 
evaluating  the  effectiveness  of  action  programs  undertaken  to  achieve  the  aims  of  that  mission.  A 
brief  discussion  of  these  elements  is  presented  in  paragraph  4. 2. 4. 3  below. 

4.2.4  Enterprise  Processes 

One  of  our  efforts  consisted  of  requirements  definition  for  and  schematic  designs  of  enterprise 
operating  system  processes.  Our  specific  tasking  was  to  provide  systematic  answers  to  the  following 
questions. 

1.  What  is  an  enterprise  process? 

2.  What  are  the  major  enterprise  processes? 

3.  Which  of  these  are  the  most  critical  to  overall  strategic  success? 

4.  What  are  appropriate  performance  measures  for  each  of  the  enterprise  processes? 

We  produced  three  principal  products  in  response  to  this  tasking.  The  first  was  a  formal  character¬ 
ization  of  all  principal  enterprise  operating  system  processes.  A  summary  of  this  is  presented  in  the 
next  paragraph.  The  second  was  a  detailed  outline  of  the  intent  formalization  process,  which  is 
one  of  the  three  critical  enterprise  processes  from  both  a  strategic  management  and  an  operating 
system  perspective.  This  is  presented  in  paragraph  4. 2. 4. 2.  The  third  was  preliminary  work  on  a  tax¬ 
onomy  of  Measures  Of  Effectiveness  (moes).  The  specific  issues  we  addressed  on  that  topic  are  sum¬ 
marized  in  paragraph  4. 2. 4. 3. 

4.2.4. 1  Enterprise  Process  Characterizations 
I  Definition 

The  following  is  an  abstract  of  an  exhaustive  formal  delimitation  of  the  taxon  enterprise  process 
which  we  produced  in  response  to  the  question: 

What  is  an  enterprise  process ? 
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This  result  enabled  practitioners  to  systematically  determine  whether  a  given  process  under  consid¬ 
eration  is,  in  fact,  an  enterprise  process,  a  subsidiary  process,  a  function,  or  an  action,  or  an  enter¬ 
prise-specific  implementation  of  one  or  more  of  these.  Such  determinations  are  critical  steps  in 
operating  system  design. 

Definition:  enterprise 

Enterprises  are  agencies  for  rendering  solutions  to  requirements  that  ultimately  originate  from  stake¬ 
holder  purposes.  Accordingly,  enterprises  are  intermediate  instrumentalities  for  accomplishing  those 
aims— the  solutions  they  produce  provision  stakeholder  operations  for  achieving  them.  We  can 
readily  infer  three  formally  useful  facts  from  this  informal  characterization  by  structuring  it  in 
terms  of  the  instrumentalization  relation  scheme.51 

1.  As  enterprises  are  implementation  agencies,  they  necessarily  stand  in  agency  attribute 
positions  of  instrumentalization  relations.  Thus,  for  a  given  enterprise  X: 

(lnstrumentalization,(lnvolvement,E/7ferpr/sex,Product)). 

2.  From  the  above  it  easily  follows  that  solutions  rendered  by  enterprises  necessarily  stand  in 
product  attribute  positions  of  these  relations.  Thus  again  for  a  given  enterprise  X: 

(Instrumentalization, (Involvement, Enterpris  ex, (Solution^... ,Solutionj,...,Solutionn))). 

3.  Purpose/operation  pairs  constituting  relations  between  stakeholder  aims  and  accomplish¬ 
ment  methods  are  the  sources  of  solution  requirements.  Accordingly  these  necessarily 
stand  in  involvement  attribute  positions: 

(Instrumentalization, ((purp^  [  opy,...,purp/]  [  opj,...,purpn]  [opn ), Enterprise^ (Solution-, ... n ))). 

Thus  in  the  context  of  the  current  question,  an  enterprise  is  an  entity  instantiating  the  agency 
attribute  of  at  least  one  instrumentalization  instance: 

(Instrumentalization, ((purp-, . . .n  ]  [  op-,  ...n  ),Enterprisex, (Solution . . .n ))) 

Definition:  Process 

Processes  are  regular  and  definite  successions  of  interrelated  activities  that  yield  consistent  and 
determinate  results.  Enterprise  processes  are  customarily  characterized  in  the  management  litera¬ 
ture  as  specific  variants  exemplifying  two  additional  characteristics.  The  first  is  applicability— that 
their  outputs  necessarily  constitute  ‘value’  to  the  ‘customers’  of  the  process.  The  second  is  exten¬ 
sive  totality  or  completeness— that  they  encompass  an  entire  ‘value  chain’  relative  to  the  ‘customers’ 
of  the  process.  This  attribute  is  why  many  call  enterprise  processes  ‘horizontal;’  or  ‘end-to-end’ 
processes.  We  will  explicate  completeness  now;  applicability  will  follow  that. 

Complete  processes  are  ontogenies— courses  of  activities  constituting  entire  entity  life  cycles  from 
beginning  to  end.  We  can  usefully  recast  this  informal  characterization  in  terms  of  the  realization 
relation  scheme,52  thereby  establishing  the  formal  fact  that  complete  processes  necessarily  stand  in 
the  occurrent  attribute  positions  of  realization  relations.  Thus  for  a  specific  complete  process  CP 
encompassing  the  life  cycle  of  a  given  entity  x  we  obtain: 

(Realization, (CPx,lnceptionx,Continuationx,Terminationx )) 

There  are  three  positional  variants  of  complete  processes  of  interest  to  us  here:  primary ,  secondary, 
and  tertiary.  These  variants  are  defined  in  terms  of  inverse  reflective  realization  order:  P-order  real¬ 
ization  instances  are  complete  tertiary  processes;  2nd-order  realization  instances  are  complete  sec¬ 
ondary  processes;  and,  3rd-order  are  of  course  primary.  Secondary  or  major  subprocesses  of  complete 
processes  are  phases  of  ontogenies— successions  of  actions  or  subprocesses  constituting  all  three 
subsidiary  subphases  of  one  of  three  specific  stages  of  entity  life  cycles.  That  is,  secondary  pro¬ 
cesses  also  necessarily  stand  in  the  occurrent  attribute  positions  of  realization  relations.  How- 

51  Instrumentalization  is  a  variant  of  the  capacitation  relation  type  defined  in  paragraph  3. 2. 5. 2  of  Section  3. 

52  Realization  is  the  occurrent  variant  of  the  correlation  relation  type. 
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ever,  as  these  are  subprocesses  of  complete  processes,  instances  of  these  relations  are  necessarily 
situated  in  at  least  one  containing  realization  instance.  Thus  for  a  specific  secondary  process  sp 
encompassing  the  inception  phase  in  the  life  cycle  of  entity  x  we  obtain: 

(RealizationXCPxXRealizationXSPxJncept'^^'^x^ont^H^^^xTerm7®^^0^  )),Continuationx,Terminationx )) 

where  for  lnceptlNCEPTI0Nx  read  “inception  phase  of  inception  phase  of  x”,  and  so  forth. 

Tertiary  or  subprocesses  of  complete  process  subprocesses  are  realization  “leaves”  relative  to  a 
particular  ontogeny.  That  is,  they  comprise  the  Towest-leveT  P-order  variants  of  complete  pro¬ 
cesses;  all  elements  of  complete  tertiary  processes  are  either  partial  processes,  actions,  or  func¬ 
tions.  Tertiaries  are  phases  of  phases  of  ontogenies  and,  as  one  can  easily  infer,  they  are  successions  of 
actions  or  subprocesses  constituting  all  three  atomic  phases  of  a  subsidiary  subphase  of  a  specific 
entity  life  cycle  stage. 

Definition:  Enterprise  Process 

In  light  of  the  preceding  definitions,  enterprise  processes  are  clearly  realization  processes  of  instru- 
mentalization  relation  elements,  satisfying  exactly  one  of  the  following  four  conditions: 

1.  The  inputs  to  the  process  are  requirements  originating  from  at  least  one  stakeholder  pur¬ 
pose,  and  the  results  of  that  process  are  solutions  to  those  requirements.  That  is,  the  pro¬ 
cess  is  a  solution  realization  process  executed  by  the  particular  enterprise  in  question. 

2.  The  inputs  to  the  process  are  one  or  more  stakeholder  purposes,  and  the  outputs  of  that 
process  are  input  requirements  to  a  solution  realization  process  and  directives  governing 
execution  of  all  enterprise  processes,  including  that  process  itself.  That  is,  the  process  is 
strategy  realization  (i.e.,  governance;  management)  process  executed  by  the  particular  enter¬ 
prise  in  question. 

3.  The  inputs  to  the  process  are  action  directives  to  the  particular  enterprise  in  question  that 
are  direct  outputs  of  a  governance  process  of  that  enterprise,  and  the  outputs  of  that  pro¬ 
cess  are  either  (a)  inputs  to  at  least  one  enterprise  process,  possibly  including  that  process 
itself,  or  (b)  infrastructure  directly  enabling  execution  of  at  least  one  enterprise  process, 
possibly  including  that  process  itself,  That  is,  the  process  is  an  enterprise  realization  process  exe¬ 
cuted  by  the  particular  enterprise  in  question. 

4.  The  process  in  question  is  either  (a)  a  complete  secondary  or  (b)  a  complete  tertiary  real¬ 
ization  process  as  defined  above  of  an  enterprise  process  satisfying  exactly  one  of  the  prior 
three  conditions.  That  is,  the  process  is  a  major  subprocess  of  an  enterprise  process  or  a 
subprocess  of  a  major  subprocess  of  an  enterprise  process. 

An  enterprise  process  is,  accordingly,  a  process  executed  by  an  enterprise  that  meets  at  least  one 
of  the  following  criteria: 

1.  it  directly  renders  a  stakeholder  solution; 

2.  it  governs  the  enterprise; 

3.  it  creates,  modifies,  or  sustains  the  enterprise  itself;  or, 

4.  it  is  a  complete  secondary  or  tertiary  enterprise  process  subprocess. 

Note  also  that  applicability— that  characteristic  obtaining  when  process  outputs  in  fact  constitute 
‘value’  to  the  ‘customers’  of  the  process—  is  defined  as  satisfaction  of  the  above  criteria. 

I  Taxonomy 

The  following  is  an  overview  of  a  formal  taxonomy  of  enterprise  processes  which  we  produced  in 
response  to  the  question: 

What  are  the  major  enterprise  processes ? 

This  result  provided  practitioners  with  an  enumeration  of  all  first  and  second-level  enterprise  pro- 
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cesses  and  their  primary  attributes,  as  well  as  third  level  processes  and  their  attributes.  This  taxon¬ 
omy  was  intended  to  be  used  by  practitioners  for  several  different  purposes,  notably  to  verify 
completeness  of  operating  system  process  designs,  and  to  assess  alignments  of  these  to  an  optimal 
configuration. 

It  is  self-evident  from  the  definition  of  the  enterprise  process  taxon  summarized  above  that 
there  are  necessarily  exactly  three  principal  or  ‘top-level’  enterprise  processes,  as  there  are  no  other 
processes  at  this  rank  that  satisfy  the  conditions  stipulated  by  that  definition.  These  are: 

1.  Strategy  Realization 

2.  Enterprise  Realization 

3.  Solution  Realization 


These  three  primary  processes  are  depicted  by  the  rows  in  Figure  19  below  labelled  purpose, 
agency,  and  artifact,  respectively. 


Figure  19.  Principal  Enterprise  Processes 


We  use  term  realization  in  a  process  name  to  informally  signify  that  the  process  is  life-cycle  com¬ 
plete  in  the  sense  defined  earlier,  and  to  distinguish  such  processes  from  those  which  are  not. 

The  vertical  axis  of  the  diagram  depicts  the  instrumentalization  relation  between  stakeholder 
purposes  the  three  primary  enterprise  processes  and  their  products,  and  is  a  graphical  rendering  of 
our  definitional  remarks  concerning  enterprise  above. 

The  secondary  or  ‘second-level’  enterprise  processes  together  with  their  principal  products,  are 
depicted  by  the  cells  in  the  diagram.  These  also  constitute  the  major  phases  of  the  primary  enter¬ 
prise  processes,  the  generic  names  of  which  are  depicted  by  the  columns  labels  in  the  diagram. 
There  are  exactly  nine  secondary  enterprise  processes.  We  will  not  describe  them  all  here.  One  of 
them  (intent  formalization,  depicted  by  the  upper- left  cell)  is  described  in  some  detail  below.  The 
three  cells  in  the  bottom  row  depict  the  processes  commonly  called  ‘Product  Definition,’  ‘Product 
Delivery,’  and  ‘Operations  &  Support’  in  defense  contracting  circles.  These  are  the  major  subpro¬ 
cesses  of  the  Solution  Realization  process.  The  three  cells  in  the  center  row  depict  specific  variants 
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of  Solution  Realization  subprocesses  representing  those  constituting  the  enterprise  operating  sys¬ 
tem  life-cycle— i.e.,  the  major  subprocesses  of  the  Enterprise  Realization  process. 

The  tertiary  or  ‘third-level’  processes  are  not  shown  on  this  diagram,  although  one  group  of 
them— the  subprocesses  of  Intent  Formalization— are  depicted  in  the  diagram  on  page  73.  There  are 
nominally  27  tertiary  processes,  all  of  which  satisfy  the  conditions  for  being  enterprise  processes  and 
are,  therefore,  important  operating  system  processes.  Due  to  similarities  among  them  which  enable 
us  to  consolidate  triples  of  them  into  a  single  process,  there  are  actually  only  9  core  tertiaries,  each 
encompassing  3  distinct  variants.  Thus  there  are,  as  a  formal  matter  of  fact,  exactly  21  significant 
processes  constituting  an  enterprise  operating  system— 9  elemental  and  12  enterprise  processes.  All 
other  processes  are  accordingly  either: 

1.  Variants  of  one  or  more  of  these  processes; 

2.  Elements  of  one  of  these; 

3.  Variants  of  elements; 

4.  Impositions  of  extrinsic  regulatory  requirements,  or; 

5.  Unnecessary,  and  therefore  superfluous. 

I  Identifications 

The  following  is  brief  summary  of  the  arguments  supporting  our  identification  of  Intent  Formaliza¬ 
tion  and  Solution  Realization  as  the  two  processes  that  are  most  critical  for  enterprise  success,  pro¬ 
duced  in  answer  to  the  following  question: 

What  enterprise  processes  are  the  most  critical  to  overall  strategic  success? 

This  identification  enabled  practitioners  to  focus  their  actions  on  maximizing  the  strategic  viability 
of  the  enterprise. 

Enterprises  are  maximally  instrumental  (effective)  in  accomplishing  stakeholder  purposes  when 
their  actions  yield  total  solutions  to  needs  and  requirements  that  are  veridical  derivatives  of  operations 
executed  by  stakeholder  to  accomplish  those  purposes.  A  formal  definition  of  total  solution  was  one 
result  of  our  activities  in  support  of  leap  and  is  not  reproduced  here,  although  an  extract  from  that 
definition  is  used  to  illustrate  the  Explication  process  in  paragraph  4. 2. 4. 2  below.  A  definition  of  “ver- 
idically  derivative”  requirement  is  sketched  in  that  same  paragraph. 

The  primary  relationship  of  interest  in  enterprise  engineering  is  accordingly  that  between 
requirements  and  solutions— namely,  the  application  relation  defined  in  paragraph  3. 2. 5. 2  of  Sec¬ 
tion  3,  and  depicted  by  red  line  in  the  diagram  in  Figure  20  below.  A  principal  formal  magnitude 
associated  with  this  relation  is  Capability,  defined  as  capacity  for  effective  action,  and  this  is  a  primary 
magnitude  of  interest  in  enterprise  operating  system  design. 

There  are  exactly  two  subsidiary  positionally  distinct  attributes  of  Capability— Value  and  Quality. 
Value  is  fitness  for  possession.  Quality  is  fitness  for  application.  These  are  the  ultimate  attributes  of  interest 
for  optimization  in  enterprise  engineering.  Capability  is  the  only  determinant  that  matters  to  stake¬ 
holders— it  is  the  quantity  of  direct  and  operant  instrumentalization  in  stakeholder  contexts— and 
Value  and  Quality  are  the  only  salient  measures  of  that  quantity  in  those  contexts.  Thus  the  central 
focus  of  successful  enterprise  engineering  is  Capability  Optimization— maximization  of  the  value  and 
quality  of  stakeholder  solutions. 

The  two  most  crucial  operating  system  processes  enabling  that  are  Intent  Formalization  and  Solu¬ 
tion  Realization.  Intent  Formalization  is  the  process  constituting  the  Definition  phase  of  the  Strat¬ 
egy  Realization  process,  depicted  by  the  upper  left  cell  of  the  diagram  in  Figure  19.  This  process  is 
summarized  in  the  next  paragraph.  Solution  Realization  is  one  of  the  three  primary  or  Top-leveT 
enterprise  processes,  depicted  by  the  bottom  row  of  that  diagram.  It  is  a  generalization  of  Product 
Realization,  designed  to  address  the  amplitude  and  multi-modality  needs  described  in  paragraphs 
4.1.1  and  4.1.2,  respectively.  A  formal  definition  of  this  process  was  still  under  development  at  the 
end  of  Mereos  Phase  III. 
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Figure  20.  The  Capability  Relation  and  Attributes 


4. 2. 4. 2  Intent  Formalization 

The  Intent  Formalization  process  is  one  of  the  two  processes  which  are  critical  to  the  strategic  suc¬ 
cess  of  an  enterprise.  This  section  presents  excerpts  of  a  document  providing  a  detailed  formal  def¬ 
inition  of  this  process.  This  document  provided  practitioners  with  information  needed  to  design  an 
enterprise-specific  implementation  of  this  crucial  process. 

I  Description 

Purposes  must  be  explicitly  defined  to  enable  actions  to  be  devised  and  executed  to  accomplish 
them.  Requirements  antecedent  to  those  purposes  must  be  identified  to  enable  the  synthesis,  devel¬ 
opment,  and  use  of  solutions  for  implementing  actions  to  accomplish  them.  Qualification  criteria 
must  be  explicitly  defined  to  enable  governance  of  these  actions,  and  to  enable  determination  of 
the  value  of  solutions  that  is  necessary  for  them  to  fully  provision  sufficiently  effective  actions. 
Thus  definitization  is  crucial  to  purpose  accomplishment. 

Some  purposes  depend  on  the  successful  attainment  of  others  in  order  for  them  to  be  accom¬ 
plished.  More  precisely,  some  of  the  states  designated  by  particular  intents  articulating  these  pur¬ 
poses  are  dependent  upon  antecedent  states.  Such  states  cannot  therefore  be  actualized  unless  the 
antecedent  states  are  also  actualized.  Thus  identification  and  analysis  are  crucial  to  purpose  accom¬ 
plishment. 

Purposes  typically  exemplify  tremendous  variations  in  several  dimensions.  They  range  from  the 
abstract  to  concrete;  from  the  unattainable  to  the  trivial;  from  the  short-term  to  the  long-term. 
Some  purposes  are  identical,  some  are  congruent,  some  are  diametrically  opposed.  Capabilities  and 
resources  are  finite.  It  is,  accordingly,  almost  always  impossible  for  an  enterprise  to  achieve  the  all 
of  the  aims  of  its  stakeholders  to  the  degrees  they  desire.  An  achievable  and  acceptable  balance 
must  be  struck.  Thus  systemization  is  crucial  to  effective  and  efficient  purpose  accomplishment. 

Intent  Formalization  is  the  enterprise  process  for  purpose  definitization  and  systemization.  This 
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Figure  21.  Intent  Formalization  Elements 


process  is  one  of  nine  secondary  enterprise  processes  and  one  of  the  three  major  subprocesses  of 
the  Strategy  Realization  process. 

The  primary  inputs  of  Intent  Formalization  are  stakeholder  purposes  and  a  formal  mission  defini¬ 
tion  for  the  enterprise.53  Its  two  primary  outputs  are  balanced  sets  of  enterprise  objectives  represent¬ 
ing  actionable  optimal  configurations  of  stakeholder  purposes,  and  associated  measures  of 
effectiveness  (moes)  for  these.  These  moes  are  accordingly  formal  determinations  of  requisite  stakeholder 
value,  as  interpreted  by  enterprise  management  so  as  to  be  consonant  with  enterprise  capabilities, 
policies,  and  environmental  constraints.  Therefore,  Intent  Formalization  is  a  generalization  of  the  pro¬ 
cess  called  Customer  Value  Determination  in  some  management  literature. 


I  Intent  Formalization  Subprocesses 


There  are  three  subprocesses  of  Intent  Formalization,  depicted  by  the  unghosted  cells  in  the  dia¬ 
gram  in  Figure  21  above. 


Intent  Explication 


53  A  summary  of  the  elements  of  the  Mission  Definition  structure  is  presented  in  paragraph  4.2.3  above. 
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The  term  explication  refers  to  the  process  of  transforming  an  informal  or  incomplete  definition  into  a 
formal  and  complete  definition— in  this  context  a  definition  of  a  stakeholder  purpose.  Explication 
is  a  variant  of  the  formal  systematic  process  called  delimitation.  Intent  explication  is  the  process  that 
transforms  informal  or  implicit  statements  of  stakeholder  purpose  into  rigorously  formal  and  sys¬ 
tematically  complete  statements  of  strategic  intent. 

The  primary  inputs  to  this  process  are,  accordingly,  statements  of  purpose  originating  from  stake¬ 
holders  themselves  and  intelligence  concerning  those  purposes.  The  outputs  are  fully  instantiated 
and  validated  instances  of  the  Architecture  Element  structure,  depicted  by  the  drawing  in  Figure  30 
on  page  99  in  Attachment  2.  These  comprise  fully  elaborated  and  analyzed  configurations  of  the 
input  purposes  in  that  form,  including  definitive  moes  for  accomplishments  of  the  explicated 
intents.  The  Architecture  Element  structure  is  a  adaptation  of  our  metasystematics  of  taxon,  tailored 
for  this  kind  of  analysis  and  for  downstream  enterprise  operating  system  design. 

Purposes,  strategic  intents  which  articulate  them,  and  objectives  representing  correlate  enterprise 
aims  are  all  special  kinds  or  variants  of  desiderative  intentions.  Desiderative  intentions  are,  in  turn, 
special  kinds  of  intentions,  all  of  which  of  interest  to  us  here  are  propositional  attitudes  sustained  by 
agencies. 

An  agency  is  either  a  self-aware  sentient  being  that  is  capable  of  autonomous  action,  or  an  inte¬ 
gral  collective  of  these  that  is  capable  of  united  and  autonomous  action.  Examples  of  the  first  are 
human  beings;  examples  of  the  second  are  enterprises  such  as  LM  Aero. 

A  propositional  attitude  is  a  mental  state  that  consists  in  a  proposition  and  an  assertoric  mode.  An 
assertoric  mode  is  an  intentional  ‘orientation’  or  kind  of  attitude  of  an  agency  with  respect  to  a 
proposition.  These  are  several  assertoric  modes.  Four  common  one  are  imperative,  declarative,  interrog¬ 
atory  and  desiderative.  A  proposition  in  imperative  assertoric  mode  is  a  directive  that  is  expressed  by  a 
command;  one  in  declarative  mode  is  a  predication  expressed  by  a  statement,  one  in  interrogatory 
mode  is  a  query  expressed  by  a  question,  and  a  proposition  in  desiderative  mode  is  an  aim  expressed 
by  statement  of  a  purpose,  intent,  or  an  objective. 

A  proposition  is  a  variant  of  phenomenological  or  cognitive  content  of  a  mental  act  that  designates 
or  objectifies  a  state  of  affairs  (soa):  for  our  purposes  here,  a  proposition  is  an  soa.54  Thus  stakeholder 
purposes,  strategic  intents,  and  enterprise  objectives  are  soas  representing  states  that  one  or  more 
agencies  aspire  to  be  actual.  Soas  were  described  in  paragraph  3. 2. 1.1,  Results  Part  I  beginning  on 
page  28.  There  we  employed  soas  as  a  notational  device  for  defining  product  representation  meta¬ 
structures.  Here  their  role  is  objective  rather  than  merely  descriptive:  the  principal  entities  involved 
in  all  three  Intent  Formalization  subprocesses  are  soas  or  soa  schemes— the  formal  structure  of  this 
kind  of  intentional  content— and  Intent  Explication  is,  for  all  practical  purposes,  taxonomic  delimitation 
of  the  elements  of  soa  schemes  representing  strategic  intents.55 

As  we  mentioned  earlier  in  paragraph  4.2.3,  the  formal  counterpart  of  top-level  projective  intent 
defined  by  the  mission  definition  we  helped  develop  for  lmas  during  mereos  Phase  III  was  Focus  On 
Total  Solutions.  We  did  not  complete  our  explication  of  this  intent  before  leap  was  overtaken  by 
events;  however  we  have  included  an  extract  of  this  to  illustrate  what  the  early  ‘descriptive’  stage  of 


54  Those  familiar  with  the  content  theory  of  intentionality  will  no  doubt  wince  at  the  conflation  of  content  with  con¬ 
cept  in  this  definition,  not  to  mention  the  conflation  of  the  intended  soa  with  its  objectification.  While  we  both 
fully  understand  and  adhere  to  these  distinctions  privately  and  while  engaged  in  our  own  formal  work,  they  are  sim¬ 
ply  not  relevant  for  our  purposes  here,  and  introducing  them  would  make  an  already  difficult  and  abstract  narrative 
even  less  accessible  than  it  already  is. 

55  Soa  schemes  were  also  described  in  paragraph  3.2. 1.1;  as  we  pointed  out  there,  they  are  really  syntactical  shortcuts 
for  delimitation  soas.  Thus  Intent  Explication  really  is  Delimitation— allowing  for  our  deliberate  conflation  of  inten¬ 
tional  content  (soa  schemes  and  their  elements)  with  object  (taxa  and  their  characters). 
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this  process  involves— to  convey  a  “feel”  for  formal  explication. 

([  ],  (focus,  (solutions,  lmas))) 

(total(indexicalization,(FocusSoa,1)))) 

Focus 

Focus  is  exactly  one  of  the  two  following  types  of  intentional  structure: 

1.  Convergence 

A  focus  is  a  multiplicity  of  intentions  satisfying  one  of  the  following  two  conditions: 

1.1.  Every  intention  constituting  that  multiplicity  objectifies  the  same  soa  as  that 
objectified  by  the  operant  intention  in  the  strategic  context  delimiting  that  mul¬ 
tiplicity  of  intentions;  that  is,  all  intentions  in  that  multiplicity  are  co-involute  to 
the  operant  intention  of  the  delimiting  strategic  context. 

OR 

1.2.  All  soas  objectified  by  all  intentions  constituting  that  multiplicity  are  congruent  to 
the  operant  intention  in  the  strategic  context  delimiting  that  multiplicity  of 
intentions. 

2 .  Interdiction 

A  focus  is  a  multiplicity  of  intentions  satisfying  exactly  one  of  the  following  two  condi¬ 
tions: 

2.1.  Every  intention  constituting  that  multiplicity  objectifies  the  same  soa;  that  is,  all 
intentions  in  that  multiplicity  are  co-involute, 

AND 

that  soa  is  the  inhibition  sufficiency  condition  for  the  soas  objectified  by  all 
operant  intentions  involved  in  the  strategic  context  delimiting  that  multiplicity 
of  intentions  which  are  divergent  from  the  operant  intention  of  that  strategic 
context. 

XOR 

2.2.  All  soas  objectified  by  all  intentions  constituting  that  multiplicity  are  congruent, 
AND 

all  soa  objectified  by  all  intentions  constituting  that  multiplicity  collectively 
constitute  the  inhibition  sufficiency  condition  for  the  soas  objectified  by  all  other 
operant  intentions  involved  in  the  strategic  context  delimiting  that  multiplicity 
of  intentions  which  are  divergent  from  the  operant  intention  of  that  strategic 
context. 

Solution 

A  solution  is  a  system  that  is  an  instrumentality  in  at  least  one  action,  where  at  least  one  conse¬ 
quent  of  that  action  is  an  antecedent  to  accomplishment  of  at  least  one  strategic  purpose. 

System 

A  system  is  a  product-process  gestalt. 
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Product 

A  product  is  a  continuant  that  is  an  output  or  reduct  of  at  least  one  occurrent. 

In  the  context  of  this  explication,  a  product  is  a  continuant  that  is  an  output  or  reduct 
of  an  at  least  one  action  or  at  least  one  process. 

Process 

A  process  is  a  nomologous  ontogen. 

In  the  context  of  this  explication,  a  process  is  a  nomologous  ontogen 
satisfying  at  least  one  of  the  following  two  conditions: 

1.  At  least  one  delta  of  at  least  one  evolute  constituting  that  ontogen  is 
an  action. 

2.  At  least  one  delta  of  at  least  one  evolute  constituting  that  ontogen  is 
a  process  satisfying  the  above  condition. 

That  is,  in  the  context  of  this  explication,  a  process  is  a  nomologous  ontogen 
in  which  at  least  one  agency  is  involved  in  its  realization. 

Gestalt 

A  gestalt  is  an  integral  co-concrescent  complex. 

Instrumentality 

An  instrumentality  is  a  means  employed  by  at  least  one  agency  in  the  execution  of 
an  action. 

Agency 

An  agency  is  one  of  two  entities: 

1.  An  agency  is  a  self-aware  sentient  being  capable  of  action. 

2.  An  agency  is  a  collective  of  self-aware  sentient  beings  capable  of 
united  action. 

Action 

An  action  is  a  nomologous  ontogen  in  which  no  delta  of  any  evolute  constituting 
that  ontogen  is  an  ontogen. 

In  the  context  of  this  explication,  an  action  is  a  nomologous  ontogen  satisfying 
both  of  the  following  two  conditions: 

1.  No  delta  of  any  evolute  constituting  that  ontogen  is  an  ontogen. 

2.  There  exists  at  least  one  fact  of  intentionality  which  is  an  enablement 
condition  of  least  one  delta  of  at  least  one  evolute  constituting  that 
ontogen. 


Intent  Derivation 

Intent  Derivation  is  the  strategic  enterprise  engineering  analog  of  the  technical  systems  engineering 
process  called  requirements  identification  and  analysis.  Like  its  analog,  Derivation  is  basically  an  inverse 
root  cause  analysis  process.  Unlike  its  analog,  Derivation  is  principally  concerned  with  the  analysis 
of  strategic  antecedence  of  all  stakeholder  intents,  not  just  antecedence  analysis  of  technical  Cus¬ 
tomer  intents— a  very  difficult  and  abstract  undertaking  indeed.  The  inputs  to  Intent  Derivation  are 
the  explicated  formal  intents  articulating  stakeholder  purposes,  created  as  outputs  of  the  Explica¬ 
tion  subprocess.  The  intermediate  outputs  of  this  process  are  fully  instantiated  and  validated  instances 
of  the  Antecedence  and  Consequence  structure  depicted  by  Figure  31  on  page  100  in  Attachment  2. 
These  structures  represent  nominal  identifications  of  intents  whose  accomplishments  constitute 
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necessary  accomplishment  conditions  for  the  input  intents,  called  antecedents.  The  final  outputs  are 
fully  instantiated  and  validated  instances  of  the  Architecture  Element  structure  for  each  antecedent 
intent.  These  are  generated  by  iterating  between  the  Derivation  and  Explication  processes,  once  for 
each  antecedent.  This  iteration  continues  until  certain  specific  termination  conditions  are 
reached.56  Thus  the  form  of  this  iteration  suggests  a  ‘spiral/  like  that  which  is  frequently  used  to 
depict  the  iterative  execution  of  the  analogous  systems  engineering  processes.  Here  one  of  the  cru¬ 
cial  elements  produced  are  definitive  moe  allocations  to  the  antecedent  intents:  these  are  essential  for 
downstream  action  programming  and  enterprise  assurance  processes. 

We  were  unable  to  complete  a  derivation  of  antecedents  to  any  particular  intent  during  mereos 
Phase  III.  However,  we  were  engaged  in  developing  a  derivation  of  Focus  On  Total  Solutions  itera¬ 
tively  in  conjunction  with  our  explication  of  that  intent,  and  again  we  have  included  an  extract  of 
from  a  working  paper  on  the  antecedents  of  totality  for  processes  to  illustrate  what  this  process 
involves— to  convey  a  “feel”  for  the  formal  derivation  process. 


Total  solutions  are  instrumentalities  for  achieving  all  strategic  purposes  of  all  stakeholders  across 
the  entire  life-cycle  of  a  given  strategic  context.  One  special  kind  of  total  solutions  are  life-cycle 
balanced  products  capable  of  being  used  by  a  customer  to  satisfy  all  their  needs  in  a  given  opera¬ 
tional  context.  Producing  definitions  of  these  special  kinds  of  total  solutions  is  the  enterprise  of 
systems  engineering.  Total  solutions  in  the  lmas  enterprise  operating  system  context  are  life¬ 
cycle  balanced  products  and  services  for  all  lmas  stakeholders.  Creating  an  enterprise  operating 
system  for  producing  and  sustaining  these  is  the  enterprise  of  enterprise  engineering. 

Total  solutions  can  only  be  realized  by  consummately  capable  agencies  possessing  complete 
and  accurate  information  executing  total  processes  supported  by  superior  technologies.  That  is, 
total  solutions  require  total  processes,  total  technics44,  and  total  information.  These  are  the  three 
principal  entailments  of  achieving  total  solutions;  all  others  follow  from  these. 

Focus  is  a  conjunction  of  two  conditions.  The  first  is  a  convergence  of  intent  among  all  the 
stakeholders  in  a  given  strategic  context— that  is,  a  sustainment  of  a  single  intent  by  all  of  them. 
The  second  is  an  interdiction  of  conflicting  intents  maintained  by  stakeholders  in  a  given  strate¬ 
gic  context— that  is,  an  inhibition  for  action  based  on  a  divergent  intent  held  by  any  of  them. 

Focus  on  the  central  intent  of  a  given  strategic  context  can  only  be  attained  by  consummately 
capable  agencies  possessing  complete  and  accurate  information  and  meta-information4S  execut¬ 
ing  total  strategic  processes  supported  by  superior  technology.  That  is,  focus  entails  a  total  strat¬ 
egy  process,  total  technics,  and  total  information;  all  other  derivative  antecedent  conditions 
follow  from  these  three. 

Total  entities— total  in  general— are  complete  and  optimal  in  the  life-cycle  of  a  given  context. 
The  condition  of  totality  differs  for  processes,  technics,  and  information. 

Total  Processes 

There  are  exactly  three  processes  constituting  the  life-cycle  of  any  given  entity.  These 
are  Provisioning,  Execution,  and  Assurance.  A  total  process  satisfies  at  least  one  of  the 
following  criteria: 

1.  It  is  an  optimal  configuration  of  an  entire  life-cycle;  that  is,  it  comprises  all  pro¬ 
visioning,  execution,  and  assurance  for  at  least  one  entity  type. 

2.  It  is  a  complete  and  optimal  configuration  of  at  least  one  of  the  above  three  pro¬ 
cesses;  that  is,  it  is  an  optimal  element  of  a  total  process. 

44  The  term  “technics”  is  used  to  cover  both  human  capability  and  technology. 

45  Information  about  information;  in  this  particular  case,  information  about  the  information  possessed  by  other  stake¬ 
holders— especially  those  maintaining  divergent  intentions.  Competitors  are  classical  examples  of  these  stakeholders, 
and  competitive  intelligence  is  a  classical  example  of  meta-information  in  this  context. 


56  Crudely  speaking,  Derivation  proceeds  until  all  identified  ‘leaf’  antecedents  are  either  (i)  already  actual;  (ii)  can  be 
actualized  by  an  ‘atomic’  action  of  an  enterprise  operating  system;  (iii)  cannot  be  actualized  by  any  possible  operat¬ 
ing  system  action  or  process— i.e.,  are  scope-extrinsic ;  or  (iv)  define  the  same  condition  as  at  least  one  other  antecedent 
or  (b)  are  variants  of  other  antecedents,  such  that  they  satisfy  conditions  (ii)  or  (iii). 
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3.  It  is  a  complete  and  optimal  configuration  of  a  permissible  variant  of  a  total  pro¬ 
cess  or  an  element  of  a  total  process. 

4.  It  is  demonstrably  traceable  process  requirement  imposed  either  by  stakeholders 
with  governing  authority  over  the  enterprise,  or  by  the  Lmas  Constitution. 

If  a  process  satisfying  the  fourth  criterion  above  does  not  also  satisfy  one  of  the  other 
three,  then  the  process  is  defective— it  is  not  total.  This  condition  is  an  effectivity  for  a 
corrective  action  process  which  must  as  defined  in  the  architecture  and  implemented 
by  the  operating  system. 

An  enterprise  operating  system  process  is  a  systemic  process.  An  enterprise  realization  process 
is  a  strategic  process.  Enterprise  operating  system  corrective  action  processes  are  architectonic— 
these  are  special  kinds  of  enterprise  realization  processes. 

Total  solutions  require  total  systemic  processes.  Focus  requires  total  strategic  processes. 
Autonomism  requires  architectonic  processes.  Thus  two  specific  antecedents  of  Focus  On  Total 
Solutions  are: 

1.  Execute  All  Enterprise  Actions  Via  Total  Systemic  Processes 

2.  Govern  All  Enterprise  Actions  Via  A  Total  Strategy  Process. 

Both  of  the  above  entailments  can  be  stated  by  the  following  general  imperative: 

Act  Via  Total  Processes. 


Intent  Systemization 

Intent  Systemization  is  the  strategic  enterprise  engineering  analog  of  the  technical  systems  engi¬ 
neering  process  called  system  optimization,  applied  to  stakeholder  intents  rather  than  definitions  of 
solutions  to  those.  These  two  processes  are  however  only  functional  analogs— they  have  almost 
nothing  in  common  other  than  their  roles  in  their  respective  parent  processes. 

We  have  stated  before  that  purposes— and  thus  the  intents  that  articulate  them— are  numerous 
and  diverse  in  kind.  One  side  effect  of  the  Intent  Derivation  process  is  to  increase  both  the  quantity 
of  and  the  diversity  among  these  intents,  as  antecedents  are  iteratively  identified  and  explicated.  In 
an  ideal  universe  where  capabilities  and  resources  were  infinite,  enterprise  objectives  would  be 
identical  to  stakeholder  intents,  and  achieving  these  objectives  would  represent  accomplishment  of 
all  the  intents  of  all  stakeholders.  But  of  course  this  ideal  is  an  absolute  empirical  impossibility  and 
almost  certainly  a  formal  one,  given  typical  divergences  among  stakeholder  intents— those  which 
are  diametrically  opposed  being  paradigm  examples.  Enterprise  objectives  will  never  be  identical  to 
intents.  For  exactly  these  same  reasons,  neither  will  enterprise  moes  ever  be  identical  to  stakeholder 
moes.  As  a  practical  matter  of  fact,  gaps  will  always  exist  between  what  is  desired  and  what  is  achiev¬ 
able. 

In  the  final  analysis,  there  are  only  four  fundamental  ways  to  bridge  such  gaps.  The  first  is  by 
invention— enhancing  the  effectiveness  of  existing  capabilities  or  creating  new  ones.  The  second  is 
by  acquisition— enhancing  utilization  efficiencies  of  existing  resources  or  securing  additional 
resources,  via  procurement,  exchange,  or  alliance.  The  third  is  by  exclusion— eliminating  one  or 
more  stakeholder  intents  from  the  strategic  mix.  The  fourth  is  by  systemization,  which  involves  opti¬ 
mizing  the  objectives  themselves  in  advance  of  defining  action  programs  for  carrying  them  out.  That  is, 
cogent  intent  systemization  can,  in  many  circumstances,  pre-empt  the  need  to  devise  actions  to  over¬ 
come  gaps  entailed  by  intents  that  can  be  factored  or  subsumed,  and  can  significantly  decrease  the 
amplitude  of  actions  required  to  overcome  those  that  remain.  This  last  technique  is  a  signature  of 
expertise  in  the  art  of  politics  and  a  hallmark  of  incisive  strategic  skill.  The  Intent  Systemization 
process  is  a  formalization  of  this  technique. 

The  primary  inputs  to  the  Intent  Systemization  process  are  the  validated  outputs  of  the  Intent 
Explication  and  Derivation  processes— that  is,  precisely  stated  intents,  together  with  their  anteced- 
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ents,  and  moes.  The  intermediate  outputs  of  this  process  are  formal  analyses  of  taxonomic  similarities 
and  divergences  among  the  these,  developed  using  a  self- applicative  taxonomy  of  similarity  itself 57 
Fulfilling  the  analogous  function  of  product/process  structure  optimization  in  a  strategic  manage¬ 
ment  context,  these  analyses  are  accordingly  represented  using  exactly  the  same  relations  as  those 
used  in  that  context— namely,  articulation,  lactorization,  and  unification58  relations.  Here  they 
relate  elements  of  intentional  structures,  respectively  delineating  Realization  process  segmentations, 
uniformities,  and  conjunctions  among  these.  The  final  outputs  of  this  process  are  balanced,  action¬ 
able,  and  maximally  dense  enterprise  objectives  and  moes,  defining  the  requisite  outcomes  of  enter¬ 
prise  actions.59  These  objectives  subsequently  undergo  achievability  analysis  via  the  Operational 
Analysis  process,  one  of  three  major  subprocesses  constituting  the  Action  Programming  process.  A 
primary  formal  structure  involved  in  that  process,  called  a  Strategic  Context,  is  briefly  described  in 
paragraph  4. 2. 4. 4  below.  Instances  of  these  structures  in  turn  are  the  primary  inputs  to  other  down¬ 
stream  Action  Programming  subprocesses,  and  to  the  Solution  Realization  and  Enterprise  Realiza¬ 
tion  processes. 

4. 2. 4. 3  Effectiveness  Measure  Systematics 

Qualification  criteria  must  be  explicitly  defined  to  enable  governance  of  enterprise  actions,  and  to 
enable  determination  of  the  value  of  solutions  for  instrumentalizing  the  actions  of  enterprise  stake¬ 
holders.  These  criteria  are  moes— and  defining,  imposing,  and  determining  their  states  constitute  a 
core  enterprise  process  called  Assurance.  As  we  stated  earlier,  moes  are  internalized  stakeholder  value 
impositions  on  the  enterprise— they  define  what  value  to  which  stakeholders  are  to  be  delivered  via 
execution  of  enterprise  processes.  Thus  defining  an  enterprise  operating  system  and  an  assurance 
process  for  that  system  entails  a  systematic  and  definitive  answer  the  following  question: 

What  are  appropriate  performance  measures  for  each  of  the  enterprise  processes ? 

Our  efforts  to  answer  this  question  were  incomplete  at  the  end  of  mereos  Phase  III,  although  a 
great  many  results  had  been  obtained  and  interim  documentation  produced  by  the  end  of  calendar 
2000.  The  overall  objective  of  these  efforts  is  to  specify  a  suitable  mensuration  system  for  the  nae  oper¬ 
ating  system— a  critical  mechanism  of  its  Assurance  process.  We  have  decided  not  to  incorporate 
the  text  of  these  working  papers  into  this  document,  as  they  are  exceedingly  abstract,  employ  the 
technical  language  of  our  metasystematics,  and  thus  would  be  of  little  value  to  convey  concrete 
results.  We  have  instead  summarized  the  specific  areas  we  have  focused  on  below. 

I  Measure  Of  Effectiveness  Delimitation 

Determining  specific  and  appropriate  performance  measures  for  enterprise  processes  presupposes  a 
prior  and  formally  adequate  generalized  definition  (taxonomic  delimitation)  for  the  class  measure 
of  effectiveness  itself.  No  such  delimitation  exists,  so  we  were  forced  to  undertake  its  develop¬ 
ment. 

I  Qualification  and  Quantification  Process  Definitions 

Imposing  moes  on  a  process  presupposes  that  processes  exist  for  determining  the  values  of  the  mag¬ 
nitudes  in  question.  Accordingly  we  developed  formal  definitions  of  qualification  and  quantifica¬ 
tion— the  processes  required  to  determine  the  values  of  qualitative  and  quantitative  moes, 
respectively.  The  structures  and  their  elements  associated  with  these  processes— designated  metrol¬ 
ogy  and  nomology— are  depicted  in  the  Architecture  Element  Elements  drawing  on  page  99  in 
Attachment  2. 

57  The  similarity  taxonomy  is  depicted  by  Figure  32  on  page  101  in  Attachment  2. 

58  Definitions  of  the  articulation,  factorization,  and  unification  relation  types  are  presented  in  paragraphs  3.2.4. 1, 
3. 2. 4. 2,  and  3. 2. 4. 3,  respectively,  in  Section  3.  Here  the  entities  standing  in  the  attribute  positions  of  these  relations 
are  intents  and  their  elements,  rather  than  product  structures  and  their  elements. 

59  In  many  cases,  these  objectives  can  simply  be  ‘read  off’  the  inter- intentional  relations.  That  is,  once  the  latent  dis¬ 
continuities  (articulation  relations),  intrinsic  homologies  (factorization  relations),  and  attainable  subsumptions 
(unification  relations)  among  a  given  set  of  intents  and  their  relata  have  been  delineated,  restating  these  as  enter¬ 
prise  objectives  coordinate  to  these  relations  is  a  reasonably  trivial  exercise. 
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I  Moe  Taxonomy 

There  are  dimensions  of  variation  among  enterprise  processes  that  partially  determine  the  appro¬ 
priateness  of  specific  moes  for  those  processes.  For  example,  the  Strategy  Realization  process  and 
most  of  its  secondary  subprocesses  are  abstract  and  synthetic,  while  Solution  Realization  and  most 
of  its  secondary  subprocesses  are  concrete  and  synthetic.  Moes  which  are  appropriate  for  abstract 
cognitive  processes  are  not  appropriate  measures  for  concrete  physical  ones.  There  are  several  other 
variations  among  processes  over  and  above  these  two,  all  of  which  have  implications  for  moe  impo¬ 
sition.  There  are  also  intrinsic  variations  among  moes  themselves.  For  example,  systems  engineers 
correctly  distinguish  between  performance  and  moes  expressing  requisite  degrees  of  this  attribute60 
and  effectiveness,  and  moes  expressing  requisite  degrees  of  that  one.  Without  getting  bogged  down  in 
a  long  discussion,  suffice  it  to  say  for  our  purposes  here  that  Performance  is  efficiency  of  Realization 
and  Effectiveness  is  capability  of  Realization— these  are  very  distinct  characteristics,  indeed. 

One  of  the  more  difficult  problems  involved  in  developing  a  formal  taxonomy  of  moes  for  enter¬ 
prise  processes  is  identification  of  a  suitable  set  of  basic  magnitudes.  If  we  were  embarked  on  a  project 
to  develop  such  a  taxonomy  in  a  more  concrete  domain,  this  would  not  be  a  problem.  For  example, 
there  are  several  families  of  basic  physical  magnitudes  to  choose  from— such  as  those  employed  in 
the  ‘metric’  (si)  system— and  there  are  already  a  large  number  of  ‘intentional’  magnitudes  that  must 
be  accommodated  in  any  undertaking  of  this  kind— the  gamut  of  economic  measures  being  para¬ 
digm  examples.  But  while  magnitudes  such  as  duration  and  economic  efficiency  may  be  important 
enterprise  process  moes,  at  least  to  some  stakeholders,  they  and  their  kin  are  far  from  the  only  ones  of 
significance  from  an  assurance  standpoint.  Thus  the  question  is:  if  physical  and  economic  magni¬ 
tudes  constitute  only  a  subset  of  the  magnitudes  involved  to  determine  the  performance  and  effec¬ 
tiveness  of  enterprise  processes,  what  are  the  others?  And  perhaps  even  more  importantly,  given  any 
particular  answer  to  that  question,  how  do  we  know  we  have  identified  all  the  possible  and  relevant 
magnitudes?  That  is,  how  can  we  be  sure  that  the  list  is  complete,  systematically  derived,  and  appo¬ 
site  to  the  purposes  at  hand? 

I  Purpose/Process  Taxonomy 

What  constitutes  an  acceptable  degree  of  effectiveness  or  performance  is  always  relative  to  a  spe¬ 
cific  purpose— i.e.,  a  particular  stakeholder  type.  For  example,  moes  appropriate  for  determining 
requisite  degrees  of  Customer  value  are  simply  not  the  same  as  those  for  determining  requisite 
degrees  of  Shareholder  value.  This  entails  that  the  answer  to  the  taxonomic  question  at  hand  will  be 
a  ‘vector’  of  moes  for  each  process,  each  element  thereof  representing  the  appropriate  measure  for  a 
particular  stakeholder  type  with  respect  to  that  particular  process.  There  are  10  principal  stake¬ 
holder  types,  and  21  enterprise  processes.  This  entails  that  there  are  in  principal  at  least  210  moes  for 
the  enterprise  processes.  F)eveloping  this  taxonomy  is  a  decidedly  non-trivial  endeavor. 

4. 2. 4. 4  Operational  Analysis  and  Strategic  Contexts 

A  key  requirement  identified  in  paragraph  4.2.3  above  is  that  mission  definitions  suitable  for  enter¬ 
prise  operating  system  synthesis  must  consist  in  formal  and  effective  expressions  of  strategic  intent. 
Defining  invariant  purposes  in  actionable  form,  these  constitute  the  origins  of  all  ‘top-level’  enter¬ 
prise  operating  system  requirements.  Indeed,  systematic  operating  system  design,  deployment,  and 
operation  mandates  that  all  stakeholder  purposes  must  be  formalized,  invariant  or  otherwise.  Thus 
Intent  Formalization  is  a  critical  enterprise  operating  system  process. 

Accomplishing  stakeholder  intents  requires  effective  action.  Effective  action  by  enterprises  via 
their  operating  systems  presupposes  prior  definition,  and  these  definitions— action  programs— are 
the  primary  outputs  of  the  Action  Programming  process.  Action  Programming— i.e.,  enterprise 
operating  system  programming— is  the  Development  phase  of  the  Strategy  Realization  process, 
depicted  by  the  middle  cell  in  the  top  row  of  the  diagram  in  Figure  19.  The  principal  inputs  of  this 
process  are  enterprise  objectives  and  moes  defined  by  the  Intent  Systemization  subprocess  of  Intent 
Formalization.  Stipulating  requisite  outcomes  of  enterprise  actions,  these  objectives  and  moes  con- 


60  These  are  called  Technical  Performance  Measures  (tpms)  in  systems  engineering. 
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stitute  the  governing  functional,  performance,  and  effectiveness  requirements  for  synthesis  of 
action  programs  to  achieve  them. 

Like  its  analog  in  product  definition  contexts,  action  program  synthesis  must  also  be  governed  by 
additional  constraints  over  and  above  the  functional,  performance,  and  effectiveness  requirements 
represented  by  enterprise  objectives  and  moes.  One  of  the  most  crucial  of  these  is  executability— the 
analog  of  producibility  in  product  definition  contexts.  That  is,  an  action  program  that  cannot  be  exe¬ 
cuted  is  just  as  worthless  in  a  Strategy  Realization  process  context  as  an  unproducible  design  is  in  a 
Product  Realization  process  context.  And,  just  as  producibility  determinations  entail  prior  evalua¬ 
tions  of  extant  and  envisioned  technical  capabilities,  ascertaining  the  executability  of  action  pro¬ 
grams  necessitates  prior  evaluations  of  existing  and  postulated  strategic  capabilities,  as  those  bear 
on  accomplishing  a  given  objective.  Thus  definitive  determinations  of  feasibility  or  achievability— the 
same  thing  expressed  as  an  attribute  of  objectives  and  intents— constitute  crucial  enablements  of 
action  program  synthesis  and  subsequent  executability  evaluations  of  those  programs. 

Achievability  determinations  are  products  of  the  Operational  Analysis  subprocess  of  the  Action  Pro¬ 
gramming  process.  These  determinations  are  rendered  as  fully  instantiated  instances  of  the  Strategic 
Context  structure,  graphically  depicted  by  Figure  22  below.  This  structure  is  a  variant  of  our 


Intentional  Complex  metastructure,  adapted  to  support  the  formal  needs  of  the  Operational  Analy- 
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sis  process  and  other  downstream  Action  Programming  subprocesses— specifically,  the  Program  Syn¬ 
thesis  subprocess.  The  two  primary  functions  of  the  Strategic  Context  structure  are  to  inform 
achievability  analysis  of  stakeholder  intents  and  their  correlate  enterprise  objectives,  and  to  frame 
the  results  of  that  analysis.  This  structure  is,  accordingly,  a  formalized  and  extended  realization  of 
the  implicit  structures  employed  in  the  swot61  and  capability  assessment  processes  in  strategic  man¬ 
agement. 

I  Classification  Scheme 

The  process  of  developing  rigorous  and  detailed  characterizations  of  strategic  intent  via  the  Intent 
Formalization  process  is  inherently  difficult.  Precise  analyses  framed  in  terms  of  complex  abstrac¬ 
tions  are  required  to  achieve  meaningful  results.  Carrying  out  operational  analysis  to  determine  the 
practicability  of  accomplishing  these  intents  is  even  more  difficult.  Intrinsically  complex  material 
matters  of  fact,  such  as  enterprise  capabilities,  environmental  factors,  and  certain  specific  relation¬ 
ships  between  these— both  actual  and  implied— are  principal  subjects  of  such  analysis.  Nevertheless, 
insuring  that  results  of  enterprise  actions  are  congruent  to  stakeholder  purposes  is  the  paramount 
aim,  regardless  of  the  difficulties  involved,  and  so  operational  analysis  must  also  accordingly  insure 
that  congruence  of  actions  to  intents  is  consistently  maintained. 

Another  factor  exacerbating  the  difficulty  of  operational  analysis  is  the  sheer  constitutional  com¬ 
plexity  of  the  entities  themselves.  Agencies— enterprises  and  their  operating  systems— environ¬ 
ments,  stakeholders  and  their  actions,  and  the  solutions  necessary  to  instrumentalize  those,  are 
very  complex  systems;  that  is,  each  one  individually  is  an  integral  product-process  gestalt  and  is  typ¬ 
ically  both  taxonomically  diverse  and  quantitatively  extensive.  And,  the  relationships  among  these 
are  correspondingly  diverse  and  numerous  as  well.  However,  only  a  few  element  types,  relations, 
and  attributes  of  these  entities  are  relevant  to  this  process;  the  full  systemic  power  of  the  Architec¬ 
ture  Element  structure  taxonomy  is  simply  not  required  for  purposes  of  operational  analysis.  This 
fact  can  be  exploited  to  mediate  the  difficulties  involved  by  redacting  the  Architecture  Element  struc¬ 
ture  into  a  more  succinct  structure  for  analytic  purposes.  The  Strategic  Context  structure  is  the 
result. 

As  the  primary  aim  of  operational  analysis  is  to  ascertain  the  achievability  of  a  given  intent,  the 
central  object  in  a  Strategic  Context  structure  instance  is  the  intent  itself,  as  depicted  by  the  box 
labeled  intention  in  the  center  of  Figure  22.  All  strategic  intents  objectify  or  designate  a  specific  state 
or  states  of  affairs  (soas)  which  an  agency  or  agencies  desire  to  be  actual.  From  a  purely  formal 
point  of  view,  every  intentional  complex  comprises  the  following  elements: 

1.  the  intention  itself; 

2.  the  soa  or  soas  that  intention  objectifies; 

3.  the  agency  or  agencies  sustaining  the  intention;  and, 

4.  the  environmental  context  in  which  the  sustainment  of  that  intention  occurs. 

The  Strategic  Context  structure  eliminates  the  distinction  between  the  intent  and  the  soa  it  desig¬ 
nates— they  are  conceived  as  one  object  for  operational  analysis  purposes.  Eliminating  this  distinc¬ 
tion  is  one  step  in  redacting  the  Architecture  Element  structure  into  the  Strategic  Context  structure. 
This  is  why  there  is  only  one  element  of  that  type  in  the  structure— i.e.,  intentioNj. 

Effectivity 

The  formal  distinction  of  effectivity  between  the  actual  intent  and  the  desired  state  it  objectifies  is  not 
eliminated.  Effectivity  is  instead  employed  as  a  ‘dimension’  of  the  Strategic  Context  structure.  The 
two  ‘coordinates’  of  this  ‘axis’— operant  and  posited— are  used  in  conjunction  with  others  to  ‘grid’ 
Strategic  Context  elements  and,  thereby,  to  delineate  distinctions  between  them  which  are  signifi¬ 
cant  for  operational  analysis.  The  Strategic  Context  diagram  depicts  these  differences  in  effectivity 
both  visually  and  by  some  element  designations.  Specifically,  the  top  half  of  the  box  labeled 

61  Strength,  Weakness,  Opportunity,  and  Threat.  An  excellent  discussion  of  these  four  elements  in  a  pure  strategic  man¬ 
agement  context  can  be  found  in  David’s  Strategic  Management  Concepts;  see  our  references  5.2  and  5.3. 
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iNTENTiONj  is  grey,  while  the  bottom  half  is  red,  implicitly  depicting  the  location  of  the  axis  itself 


OPERANT  ELEMENTS 


POSITED  ELEMENTS 


Figure  23.  Effectivity  Coordinates 


Hence  the  top  half  of  the  drawing  contains  those  elements  which  are  operant— i.e.,  actual  elements 
of  the  agency  sustaining  the  central  intent  and  those  of  its  situating  environment.  The  bottom  half 
contains  those  which  are  posited— i.e.,  postulated  elements  of  the  sustaining  agency  and  its  envi¬ 
ronment  projected  by  that  intent.  We  will  describe  these  in  more  detail  shortly. 

Location 

As  we  stated  before,  all  intents  are  situated  in  specific  environments,  and  this  locative  feature  is 
employed  as  the  second  ‘dimension’  of  the  Strategic  Context  structure.  The  two  coordinates  of  this 
axis —adjunct  and  advenient— are  used  to  distinguish  Strategic  Context  elements  which  are  extensions 
of  intents  from  extrinsic  elements  comprising  them.  One  can  envision  this  axis  an  imaginary  verti¬ 
cal  line  through  the  center  of  the  Strategic  Context  diagram,  with  adjunct  elements  positioned  on 
the  right  and  environmental  elements  on  the  left. 


Figure  24.  Location  Coordinates 


Combining  both  the  effectivity  and  location  dimensions,  we  obtain  four  ‘quadrants,’  each  con- 
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taining  a  specific  category  of  Strategic  Context  element  types. 


OPERANT/  ADVENIENT 
ELEMENTS 


OPERANT/ ADJUNCT 
ELEMENTS 


POSITED/ AD  VEN IENT 
ELEMENTS 


POSITED/ADJUNCT 

ELEMENTS 


Figure  25.  Element  Type  Quadrants 


I  Elements 

INSTRUMENTALIZATION  AND  APPLICATION  RELATIONS 

Achieving  an  intent  is  an  outcome  of  effective  actions  or  processes.  That  is,  realizing  a  posited  soa  pro¬ 
jected  by  a  desiderative  intent  entails  execution  of  an  action  or  a  process  that  results  in  at  least  one 
of  the  following: 

1.  that  soa  becoming  actual; 

2.  an  instance  of  that  soa  scheme  becoming  actual;  or, 

3.  an  admissibly  congruent  soa  becoming  actual. 

Any  intents  necessitating  the  effort  of  operational  analysis  cannot  be  directly  achieved  by  atomic 
actions.  They  entail  complex  realization  processes  to  achieve  them  and  correspondingly  complex 
instrumentalities— i.e.,  solutions— to  provision  the  execution  and  governance  of  these  processes. 
Realization  of  the  instrumental  solutions  in  turn  entails  agencies  with  the  capabilities  required  to 
render  them,  and  typically  these  are  different  agencies  than  those  executing  intent  realization  pro¬ 
cesses.  That  is,  one  agency  typically  executes  one  or  more  operations  to  realize  the  intent,  thereby 
performing  the  role  of  effective  agent  in  a  given  strategic  context.  Another  agency  executes  the 
entailed  solution  realization  process,  thereby  performing  the  role  of  instrumental  agent  in  that  con¬ 
text.  Even  if  the  same  agency  fulfils  both  the  effective  and  the  instrumental  roles  in  a  given  strategic 
context,  that  agency  will  exemplify  distinct  characteristics  with  respect  to  each  of  those  roles. 
Moreover,  its  relations  to  the  remaining  elements  constituting  that  context  will  accordingly  differ, 
and  so  will  the  attributes  of  interest  for  operational  analysis  it  exemplifies  in  each  of  those  roles. 
Again  however,  these  roles  are  typically  performed  by  distinct  agents. 

In  light  of  the  above  remarks  we  can  now  introduce  the  two  groups  of  Strategic  Context  ele¬ 
ments— the  relation  types  instrumentalization  and  application,  their  attributes,  and  the  entity 
types  standing  in  those  attribute  positions.  These  two  relations  are  respectively  the  functional  and 
dispositional  variants  of  the  capacitation  relation  type,  defined  in  paragraph  3. 2. 5. 2  in  Section  3. 
Instrumentalization,  the  relation  of  agential  provisionment,  is  the  formal  structure  invoked  in  our 
characterization  of  the  enterprise  taxon  in  paragraph  4. 2. 4.1,  and  is  consequently  a  primary  rela¬ 
tion  among  the  three  ‘top-level’  enterprise  processes,  as  illustrated  by  the  diagram  in  Figure  19. 
Operant  and  posited  variants  of  this  relation,  together  with  the  entity  types  in  those  attribute  posi¬ 
tions,  comprise  a  major  group  of  Strategic  Context  elements  as  well.  The  diagram  in  Figure  26  below 


84 


illustrates  this  intersection  between  the  Strategic  Context  structure  and  the  Enterprise  Process  Tax¬ 
onomy  by  overlaying  the  elements  they  share. 


Figure  26.  Strategic  Contexts  and  Enterprise  Process  Definition  Phases 

Note  that  only  the  posited  instrumentalization  relation  and  attribute  elements  are  shown  ung¬ 
hosted  in  this  diagram.  The  red  45°  line  drawn  through  the  upper  right  quadrant  in  the  above  figure, 
connecting  the  boxes  labelled  intentioNj,  posited  agency,  and  posited  offerings,  depicts  the  posited  vari¬ 
ant  of  this  relation  and  its  elements.  Its  operant  counterpart  and  elements  are  depicted  along  the 
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grey  45°  line  drawn  through  the  upper  left  quadrant  above  (upper  right  in  the  normal  orientation); 
these  can  be  seen  more  easily  in  Figure  22  than  in  the  above  diagram. 

Application,  the  relation  intrinsic  provisionment,  is  the  relation  bearing  the  determining 
attributes  of  stakeholder  value,  as  was  illustrated  by  the  diagram  in  Figure  20.  Both  operant  and  pos¬ 
ited  variants  of  this  relation,  together  with  the  entity  types  in  its  attribute  positions,  comprise  a 
second  major  group  of  Strategic  Context  elements.  The  black  line  labelled  operant  value  in  the 
above  figure,  which  connects  the  boxes  labelled  OPERATiONj  and  soLUTiONj,  depicts  the  posited  variant 
of  this  relation  and  its  elements.  Again,  its  operant  counterpart  and  the  elements  of  that  applica¬ 
tion  variant,  which  appear  opposite  to  its  posited  counterpart,  can  be  seen  more  easily  in  Figure  22 
than  in  the  above  diagram. 

Environments 

Again,  all  intents  are  situated  in  specific  environments,  and  so  are  both  the  effective  and  instrumen¬ 
tal  agencies  that  sustain  them.  Environments,  their  elements,  stakeholder  agencies,  and  the  opera¬ 
tions  they  execute  to  achieve  their  aims  accordingly  constitute  another  group  of  Strategic  Context 
element  types. 

Strategic  Magnitudes 

The  remaining  Strategic  Context  structure  elements  are  magnitudes  collectively  determining  intent 
achievability.  These  magnitudes  fall  into  two  major  categories— Contrast  and  Capacity  for  Effective  Action 
(cea). 

As  we  pointed  out  earlier,  gaps  will  inevitably  exist  between  what  stakeholders  desire  and  what 
enterprises  can  actually  achieve.  While  many  of  these  can  be  abated  in  advance  via  the  Intent  Sys- 
temization  process,  some  will  almost  certainly  remain.  On  the  other  hand,  capability  and  resource 
surfeits  will  frequently  exist  as  well.  Identifying  these  gaps  and  surfeits  and  characterizing  them  in 
terms  of  these  two  categories  of  magnitudes  is  the  main  focus  of  operational  analysis. 

Contrast 

The  operant  and  posited  configurations  of  Strategic  Context  elements  relative  to  a  particular  intent 
typically  differ.  Thus  the  achievability  of  an  intent  by  the  operant  configuration  of  an  enterprise  in 
its  operant  environment  will  almost  certainly  diverge  from  the  achievability  of  that  intent  by  the 
entailed  or  posited  enterprise  configuration  in  the  projected  environment.  Any  such  divergences 
will  have  ramifications  for  both  capabilities  and  resources.  Accordingly,  one  task  required  to  estab¬ 
lish  intent  achievability  involves  determining  two  correlated  sets  of  values  expressing  these  differ¬ 
ences.  The  first  set  comprises  Contrast  values  between  operant  and  posited  configurations  of 
entities  in  instrumentalization  attribute  positions— namely,  enterprise  and  solution  configura¬ 
tions.  These  are  called  Congruence  and  Resemblance  values,  respectively,  and  are  depicted  above  the 
“delta”  symbols  on  the  right  side  of  Figure  27  below.  The  second  set  consists  in  Contrast  values 
between  operant  and  posited  environment  configurations  situating  the  intent  and  stakeholder 
operations.  These  are  called  Fluency  and  Perpetuation  values,  respectively,  are  depicted  above  the 
“delta”  symbols  on  the  left  side  of  Figure  27. 

Cea 

Cea  also  consists  in  two  distinct  but  correlated  sets  of  values.  The  first  set,  called  instrumental  cea, 
comprises  cea  values  representing  the  abilities  of  instrumental  agencies  to  render  solutions 
required  to  provision  accomplishment  of  the  intent.  The  second  set,  called  functional  cea,  comprises 
cea  values  representing  the  abilities  of  stakeholders  sustaining  the  intent  to  achieve  it  and  thus 
other  superordinate  intents,  via  operations  employing  enterprise  solutions.  Both  of  these  sets  are 
summations  of  operant  and  posited  values  of  the  same  attributes.  The  operant  and  posited  values  of 
instrumental  cea  are  called  Fitness  and  Feasibility,  respectively,  depicted  above  the  “sigma”  sym¬ 
bols  on  the  top  and  bottom  of  Figure  28  below.  The  operant  and  posited  values  of  functional  cea 
are  called  both  called  Value— i.e.,  the  attribute  of  the  Capability  relation  defined  in  paragraph 
4.2.4. 1.  Determining  these  two  sets  of  cea  values  is  the  primary  product  of  Operational  Analysis. 
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Figure  27.  Contrast  Variants 


Figure  28.  CEA Variants 
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Every  tool  carries  with  it  the  spirit  by  which  it  has  been  created.’ 

Werner  Karl  Heisenberg,  1958 


5 

CONCLUSIONS 


Product  data  are  the  premier  informatic  capital  of  industrial  enterprises,  and  the  overall  quality  of 
these  assets— their  completeness,  accuracy,  accessibility,  and  maintainability— are  major  determi¬ 
nants  of  enterprise  performance  and  vitality.  The  processes  and  supporting  infrastructure  that  pro¬ 
duce  and  sustain  these  data  are  thus  critical  and  systemic  elements  of  enterprise  operating  systems, 
and  endeavors  aiming  to  improve  the  effectiveness  of  either  of  these  are  directly  focused  on 
enhancing  the  value  enterprises  can  deliver  to  their  stakeholders. 

There  is  certainly  no  dearth  of  technical,  strategic,  or  socio-economic  obstacles  impeding  real¬ 
ization  of  substantive  gains  in  product  representation  process  effectiveness  and  infrastructure  capa¬ 
bility.  As  one  informed  Air  Force  lab  director  once  dryly  observed,  “It’s  a  target-rich  environment.” 
In  our  view  two  of  these  impediments  stand  out  with  a  certain  extreme  acuity.  The  first  is  very 
technical  indeed—  it  is  the  metasystematic  deficiency  that  lies  at  the  heart  of  both  the  representa¬ 
tional  shortcomings  of  existing  information  systems  we  discussed  at  length  in  Section  3,  and  the 
methodological  gap  we  described  in  Section  4.  The  second  obstacle  is  essentially  socio-economic  in 
nature,  although  there  are  strategic  overtones  to  it  as  well.  This  impediment  consists  in  the  wide¬ 
spread  diminishment  in  understanding  of  product  representation  process  and  infrastructure 
requirements  in  industrial  organizations,  their  consequent  abrogation  of  control  over  those  to 
commercial  software  vendors,  and  the  resulting  albeit  unsurprising  conf  lation  of  total  process  solu¬ 
tions  with  information  systems. 

Existing  product  representation  processes  in  industrial  enterprises  are  segmented  to  align  with 
the  Definition,  Development  and  Support  subprocesses  of  Product  Realization  processes.  This  parti¬ 
tioning  compartmentalizes  the  organizational  and  information  systems  infrastructure  elements  of 
these  processes  as  well— the  famous  ‘wall’  between  engineering  and  manufacturing  organizations 
and  the  well-known  difficulties  encountered  by  those  attempting  to  integrate  pdm  and  erp  systems 
being  two  particularly  illustrative  cases  in  point.  These  divisionalizations  are  have  a  long  historical 
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standing  in  industry  and  are,  therefore,  familiar  to  all  and  accepted  as  the  natural  order  of  things  by 
many.  Nevertheless,  they  are  artificial,  suboptimal,  and  in  light  of  both  the  product  representation 
and  enterprise  operating  system  needs  previously  described,  they  are  outdated  and  constitute  a  seri¬ 
ous  impediment  to  meeting  those  needs. 

Recognition  by  many  industrial  enterprises  of  problems  attributable  to  unnecessary  and  excessive 
divisionalization  was  a  major  impetus  for  their  enthusiastic  adoption  of  the  Integrated  Product 
Development  (ipd)  model  of  the  Product  Realization  process  and  Integrated  Product  Team  (ipt) 
organizations.  And,  those  enterprises  that  implemented  this  inherently  integrative  approach 
achieved  significant  gains  in  Product  Realization  performance  and  effectiveness  as  a  result.  How¬ 
ever,  achieving  the  full  potential  of  large-scale  enterprise  process  integration  entails  suitably  capa¬ 
ble  infrastructure  over  and  above  the  organizational  element.  Specifically,  realizing  that  potential 
and  sustaining  the  resulting  gains  entails  equally  integrative  information  systems— and  such  systems 
just  do  not  exist  today.  Moreover,  such  sweeping  changes  in  an  enterprise’s  Product  Realization  pro¬ 
cess  entails  commensurate  and  carefully  coordinated  architectural  changes  to  all  its  other  major 
enterprise  processes— and  the  requisite  methodological  technics  to  accomplish  that  with  a  reason¬ 
able  certainty  of  success  do  not  exist  either.  Our  objective  was  to  bring  these  tools  closer  to  reality 
than  they  were  at  the  beginning  of  the  mereos  program. 

The  adolescence  of  enterprise  engineering  as  a  discipline  constitutes  a  significant  strategic  oppor¬ 
tunity  for  an  innovative  academic  organization  to  establish  itself  as  a  pre-eminent  provider  of 
research,  practical  applications,  and  graduates  in  this  interdisciplinary  field.  In  pursuit  of  that 
opportunity,  an  academic  institution  would  need  to  conduct  focused  research  to  fill  gaps  in  enter¬ 
prise  engineering  principles  and  methods,  thereby  strengthening  the  foundations  of  that  discipline, 
enabling  the  eventual  codification  of  its  methods,  and  provisioning  actions  to  fulfill  the  needs  we 
have  presented  here. 

The  Air  Force  may  at  some  point  find  it  in  their  interests  to  play  a  role  in  such  an  endeavor  as 
well.  One  potential  role  would  comprise  a  second  iteration  of  its  most  successful  industrial  base 
program— the  Integrated  Computer-Aided  Manufacturing  (icam)  program— focused  this  time  on  fos¬ 
tering  development  of  solutions  to  the  needs  currently  confronting  the  aerospace  and  defense 
industry,  some  which  we  summarized  in  this  document.62 


62  The  icam  program  was  veritable  fountain  of  novel  and  valuable  technology.  For  example,  it  created  the  first  full-scale 
idealized  enterprise  architecture,  called  the  Factory  of  the  Future  (FoF).  Icam  also  funded  and  managed  development 
of  a  plethora  of  technologies  designed  to  satisfy  FoF  architecture  requirements.  Notable  among  these  were  the  ICAM 
Definition  Language  (idef),  the  Integrated  Information  Support  System  (PS2,  the  second  attempt  to  build  a  3-schema 
dbms),  the  designs  for  the  ipd  process  mentioned  above,  the  Product  Definition  Exchange  Standard  (pdes,  which  later 
became  step),  advanced  Machining,  Composites,  and  Assembly  centers,  and,  late  in  the  program,  the  first  experimen¬ 
tal  version  of  our  own  pacis  system. 
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Slanted  heavily  towards  the  cladistic  conceptions  of  taxonomy  and  classification,  this  text  is  nevertheless  a  valuable 
aid  to  understanding  the  fundamental  concepts  of  biological  systematics.  A  downloadable  version  in  pdf  format  of 
this  document  is  available  at  http://www.nhmku.edu/cc.html. 
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ATTACHMENTS 


|  ATTACHMENT  h  COMMENTS  CONCERNING  STEP 


This  attachment  presents  an  overview  and  some  comments  on  step,  developed  mid-way 
through  mereos  program  execution.  We  conducted  this  review  in  orderto  determine  the 
representational  depth  of  those  of  that  standard’s  meta-level  structures  pertaining  to  our 
interests  in  the  mereos  program  context.  Current  information  about  step  can  be  found  on 
many  websites,  <http://www.nist.gov/sc4/>  and  <http://pdesinc.aticorp.org/>  are  reasonable 
starting  points. 


The  STandard  for  the  Exchange  of  Product  model  data  (step)  is  an  officially-sanctioned  standards 
development  project  conducted  by  iso  tc184/sc4/wg3,  the  International  Organization  for  Standard¬ 
ization,  Technical  Committee  184  (industrial  Automation  Systems) /Subcommittee  4  (industrial  Data 
and  Global  Manufacturing  Languages) /Working  Group  3  (Product  Modeling).  The  actual  step  stan¬ 
dard  is  iso  10303  Industrial  Automation  Systems  -  Product  Data  Representation  and  Exchange.  The 
standard  is  comprised  of  many  parts,  each  addressing  a  particular  aspect  of  product  modeling.  Dif¬ 
ferent  parts  of  the  standard  are  currently  at  various  levels  of  review  and  approval  as  international 
standards. 

Step  is  described  as  a  conceptual  specification  that  forms  a  basis  for  communicating  product 
information  at  all  stages  in  a  product  life  cycle,  covering  all  aspects  of  product  description  and 
manufacturing  specifications,  step  is  intended  to  support  approaches  such  as  concurrent  engineer¬ 
ing  and  integrated  product/process  development.  The  step  standard  addresses  the  data  required  to 
develop,  analyze,  manufacture,  document  and  support  products  ranging  from  mechanical  products 
to  electronic  products,  and  from  ships  and  airplanes  to  factories  and  office  buildings.  There  are  four 
primary  components  to  step: 

1.  The  express  data  modeling  language  used  to  define  all  step  data; 

2.  The  actual  schemas  or  definitions  (i.e.,  data  models)  of  step  data,  including  product  geome¬ 
try,  topology,  shape,  representation,  features,  tolerancing,  structure  and  process  specifica¬ 
tions; 

3.  The  application  programming  interface,  called  sdai  (Step  Data  Access  Interface),  which  is  a 
standard  interface  to  enable  applications  to  access  and  manipulate  step  data;  and 

4.  The  step  Physical  File,  which  is  (initially)  an  ascii  format  file  used  for  data  exchange 
between  or  among  systems. 

The  step  standard  is  envisioned  as  being  implemented  at  four  levels  over  time.  The  levels  are: 
Level  1  ASCII  Text  File  Exchange;  Level  2  Working  Form  Exchange  or  Application  Program  Interface; 
Level  3  Shared  Database;  and  Level  4  Knowledgebase.  Most  of  the  current  work  is  directed  at  levels 
2  and  3. 

The  primary  part  of  iso  10303  —  the  step  standard  —  related  to  the  topic  of  product  structures 
(including  boms)  is  iso  10303-44  Integrated  Generic  Resources:  Product  Structure  Configuration. 
This  part  addresses  all  major  aspects  of  product  structure  and  configuration  management  including: 
definition  of  part  versions;  release  and  approval;  assemblies;  configuration  management  of  assem¬ 
blies,  etc.  There  are  also  other  parts  that  relate  at  least  partially  to  the  topic  of  product  structuring. 
These  include: 

I  iso  10303-41  Integrated  Generic  Resources:  Fundamentals  of  Product  Description  and  Sup¬ 
port; 

I  iso  10303-42  Integrated  Generic  Resources:  Geometric  and  Topological  Representation;  and 

I  iso  10303-43  Integrated  Generic  Resources:  Representation  Structures  (also  referred  to  as 
the  product  shape  integration  model). 

It  should  be  noted  that  implementation  of  the  standard  in  the  form  of  cad  systems  and  other 
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information  technology  may  reflect  different  divisions  or  packaging  than  the  parts  of  the  standard 
itself  For  example,  it  is  envisioned  that  a  step  system  for  a  manufacturing  enterprise  might  have  sys¬ 
tem  components  for:  features  analysis/feature-based  design,  geometry  development;  mechanical 
cad,  electrical  cad,  finite  element  modeling,  bom  processing,  versioning/configuration  manage¬ 
ment,  material  forecasting,  and  manufacturing  process  development. 

The  parts  of  the  standard  noted  above  are  generic  data  models.  There  are  also  resource  models  that 
are  intended  to  provide  information  in  generalized  application  domains.  They  draw  on  the  generic 
models,  specializing  them  as  necessary.  Examples  are  models  for  finite  element  analysis  and  kine¬ 
matics.  Additionally,  there  are  application  protocol  data  models  that  target  specific  application 
domains.  Examples  are  sculptured  surface  models  and  two-dimensional  drafting  models.  These  can 
be  furthered  specialized  to  application  areas  such  as  mechanical,  electronics,  architectural,  and 
process  industries. 

Data  models  comprising  the  step  standard  can  also  be  categorized  based  on  the  level  at  which 
they  address  their  subject  area.  These  categories  can  be  described  as:  data  within  a  part;  data  about  a 
part;  and  data  about  a  group  of  parts.  ‘Data  within  a  part’  is  the  data  that  is  used  to  describe  the 
physical  nature  of  the  part  itself,  such  as  its  topology  and  geometry.  ‘Data  about  a  part’  is  related  to 
the  part,  but  is  not  directly  associated  with  the  description  of  the  nature  of  the  part.  This  data 
includes,  for  example,  part  name  and  part  number,  security  classification,  approvals,  revision  status, 
material,  etc.  Some  of  this  data  is  data  that  might  typically  be  associated  with  a  bom,  particularly  a 
bom  for  a  component  part.  ‘Data  about  a  group  of  parts’  focuses  on  assemblies.  Examples  of  this 
type  of  data  include  which  versions  of  what  parts  go  into  an  assembly  and  where  each  component 
part  or  subassembly  is  located  in  the  context  of  the  assembly  space.  In  other  words,  this  data 
addresses  traditional  parts  lists  or  engineering  boms,  but  also  contains  additional  information  relat¬ 
ing  to  component  usage  or  location  on  the  assembly.  That  additional  data  was  noted  as  being  useful 
to  manufacturing  personnel  for  actually  assembling  the  part.  In  this  sense,  the  step  concept  of  an 
engineering  bom  can  include  additional  data  intended  to  assist  with  the  manufacturing  of  the  part. 

The  step  standard  supports  different  representations  of  a  part,  but  these  differences  seem  to  relate 
largely  to  scale  and  form,  i.e.,  how  much  detail  is  provided  or  what  presentation  format  is  used.  For 
example,  it  is  noted  that  most  design  engineers  and  manufacturing  engineers  need  a  detailed  prod¬ 
uct  model.  However,  in  cases  where  the  product  model  is  exchanged  with  a  customer  or  supplier, 
some  details  of  the  part  structure  may  be  hidden  to  protect  proprietary  part  designs.  It  was  also 
noted  that  product  models  and  related  documentation  used  for  support  activities,  such  as  mainte¬ 
nance,  only  need  to  show  replaceable  part  units  and  can  often  be  presented  in  simple  2-D  form 
rather  than  as  3-D  solid  models. 

In  summary,  the  step  standard  is  intended  to  produce  a  single,  logical  product  model  that  can  be 
consistently  accessed  and  shared  across  the  various  activities  performed  throughout  the  life  cycle 
and  their  supporting  information  systems,  step  does  not  preclude  allowing  specialized  data  to  be 
layered  onto  core  generic  data  models,  and  in  fact,  supports  this  approach  through  a  deliberately 
layered  data  architecture.  By  the  same  token,  the  standard  does  not  provide  any  explicit  support  for 
encoding  and  relating  multiple  boms.  Also,  the  step  standard  in  its  general  tone  seems  to  encourage 
an  overall  concept  of  part  data  standardization  (in  the  sense  of  reducing  any  unnecessary  variabil¬ 
ity)  across  the  life  cycle,  coupling  that  with  the  concept  of  multiple  presentations  (’views’).  This 
seems  to  indicate  a  preference  for  creating  a  common  bom  with  some  (albeit  maybe  limited)  spe¬ 
cialization  and  with  multiple  presentations. 

Step  and  Multiple  boms 

The  step  product  structure  model  —  as  represented  in  logical  or  abstract  form  in  iso  10303  Parts  41, 
43  (minimally)  and  44,  and  physically  (i.e.,  ‘implementationally’)  in  ap  203  (and  to  some  degree  in 
ap  208  as  well)  —  is  officially  neutral  with  respect  to  multiple  boms.  Specifically,  the  step  view  is 
some  enterprises  allow  them,  some  don’t,  so  the  step  model  should  support  representation  of  mul¬ 
tiple  boms,  but  within  the  same  basic  model  framework  as  the  basic  bom  (i.e.,  no  or  only  minimal 
data  structures  should  be  defined  to  explicitly  support  bom  multiplicity,  and  anything  that  does  sup¬ 
port  this  approach  should  not  affect  or  otherwise  change  the  other  portions  of  the  data  model). 

The  original  data  entity  structure  was  replaced  by  another  entity  called  product_ definition, 
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which  as  one  would  expect  is  the  top-level  product  structure  entity.  It  basically  does  the  same  thing 
as  structure,  only  it  also  has  some  other  general  data  elements  that  were  deemed  appropriate  for 
the  highest-level  entity.  As  with  structure,  one  can  establish  pointers,  or  at  a  minimum  a  system 
implemented  based  on  this  standard  could  determine  that  their  were  multiple  boms  based  on  the 
fact  that  there  would  be  many  (more  than  one  at  least)  product_ definition  entities  for  the  same 
part.  (Note  that  how  “same”  The  model  also  still  contains  make_from_usage,  which  is  the  main  data 
entity  intended  to  deal  both  with  raw  material  and  ‘factorization’  issues. 

These  data  entities  are  in  Parts  41  and  44  of  iso  10303,  but  not  in  ap  203,  which  is  intended  to  be 
much  narrower  in  focus  (they  deliberately  did  not  want  to  get  into  the  multiple  bom  issue  in  this 
ap).  Ap  203  is  both  a  specialization  and  application  of  Parts  41  and  44.  ap  203  is  specialized  in  the 
sense  that  in  order  to  apply  Parts  41  and  44,  certain  things  in  the  abstract  data  models  were  left  out 
or  further  restricted.  For  example,  all  the  parent-child  relations  or  constraints  in  ap  203  are  binary, 
i.e.,  they  do  not  allow  for  the  additional  conventions  introduced  to  handle  other-than-next-higher 
assembly  pointers  or  similar  conditionals.  Something  like  60+  additional  rules  or  constraints  were 
introduced  into  the  model  to  make  it  Tmplementable’.  Rule  15  is  the  closest  rule  dealing  with  the 
multiple  bom  issue— but  it  really  addresses  versioning  or  configuration  management  issues,  not  mul¬ 
tiple  boms.  Ap  203  does  not  go  very  far  into  configuration  management,  however.  The  ap  that  is 
most  directly  tackling  this  issue  (and  may  have  some  multiple  BOM-related  data  structures  based  on 
versioning  productdefinition)  is  ap  208  Life-Cycle  Change  Management.  As  of  this  writing,  ap  208  is 
just  now  out  for  comment  in  draft  form. 
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|  ATTACHMENT 2  A2  FORMATTECHNICAL  DRAWINGS 
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Figure  29.  Taxon  Phylogeny  and  Taxonomy 
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1.  This  drawing  is  sheet  1  of  8  which  collectively  depict 
the  principal  elements  of  Ontek  metasystematics.This 
particular  drawing  depicts  the  phylogenetic  derivation 
of  the  fact  taxis,  together  with  its  metasystematic 
variants,  possible  extensional  structures,  and  coordinate 
categorial  constructs. The  schematic  elements  of  this 
drawing  depicting  axial  and  extensive  elements  of  these 
structures  (the  grey  boxes)  are  incomplete  and  hence 
not  as  yet  definitive. 

-TO  BE  COMPLETED  AT  A  LATER  DATE- 

2.  The  metatype  attribute  of  taxis  phyle^  indicates  the 
inframetataxic  configuration  of  the  metasystematic 
configuration  phyle.  Possible  variants  of  these  are: 

•  Phyle 

•  Subphyle 

•  Deme 

•  SUPERPHYLE 

•  Allophyle 

•  Homotaxic  multphyle 

•  Heterotaxic  multphyle 

-TO  BE  COMPLETED  AT  A  LATER  DATE- 
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Figure  30.  Architecture  Element  Elements 


99 


ffcfcfcfci* 


Figure  31.  Antecedence  and  Consequence  Taxonomy 
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An  antecedent  is  an  involute  of  a  heternomous  involvement 
(  ]_L[  )  synvolute  to  the  initial  incept  (f)  evolute  of  a 
prehension.  A  consequent  is  a  synvolute  of  a  heteronomous 
involvement  involute  to  a  continuation  (J*)  evolute  of 
a  prehension.  A  prehension  is  the  poietic  phase  of  an 
involvement. 

2.  A  condition  is  an  involute  involvement  of  a  heteronomous 
involvement  ( ]_L[ )  whose  synvolute  is  the  initial  incept 
(f)  evolute  of  a  prehension.  An  effectivity  is  one  or 
more  enablements.  An  enablement  is  a  thetic  (<?) 
condition-a  positive  prehensive  fundament  of  the 
genesis  of  a  prehension.  An  inhibition  is  one  or  more 
interdictions.  An  interdiction  is  the  opposite  of  an 
enablement-it  is  a  kenonic  (e*)  condition. 

An  element  is  an  involute  fact  of  a  heteronomous 
involvement  whose  synvolute  is  the  initial  incept  evolute 
of  a  prehension.  A  provision  is  one  or  more  inputs.  An 
input  is  a  thetic  element-a  positive  factational  funda¬ 


ment  of  the  genesis  of  a  prehension.  An  obstruction  is 
one  or  more  blocks.  A  block  is  the  opposite  of  an 
input-it  is  a  kenonic  element. 

An  effect  is  a  synvolute  involvement  of  a  heteronomous 
involvement  whose  involute  is  a  continuation  evolute 
of  a  prehension.  An  augmentation  is  one  or  more 
adjunctions.  An  adjunction  is  a  thetic  effect-a  positive 
prehensive  moment  of  the  operance  of  a  prehension. 
A  reduction  is  one  or  more  constraints.  A  constraint  is 
the  opposite  of  an  adjunct-it  is  a  kenonic  effect. 

A  product  is  a  synvolute  fact  of  a  heteronomous  involvement 
whose  involute  is  a  continuation  (J+)  evolute  of  a 
prehension.  A  yield  is  one  or  more  outputs.  An  output 
is  a  thetic  product-a  positive  factational  moment  of 
the  operance  of  a  prehension.  A  reduct  is  the  opposite 
of  an  output-it  is  a  kenonic  product. 
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Figure  32.  Similarity  Phylogeny  and  Taxonomy 
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Figure  33.  Metastructure  Elements  and  Examples 
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|  {STAKEHOLDER  PURPOSE-),. .  .n}<~>BALANCED  SOLUTIONS  | 

FISCAL  METRICS<~>VALUES;  PRODUCTSOMARKET  SHARES  | 

MIL-Q-98580ISQ9000;  SUPPLIER^SUPPLIERp _ | 

materielo(make,buy);  STRAT  PGMO(cONTINGENCY-| ,. .  ,n)  | 

product  realztno(dod  variant,comrcl  variant)  | 

ACTION-^ACTION^  OBJECTIVES<->PRIORITIES _ | 

COLD  WAR  A&D^POST-CW  A&D;  EPA  REGS  vl  99902000  | 

|  ENTERPRISES<->(STRATEGIC  BUSINESS  UNIT^..^)  | 

|  (TASK1typeA,...,TASKypeA)OFUNCTIONAL  ORG _ | 

|  (TASKj^peX,. .  ♦,TASK[ypeY)^PROCESS  ORG _ | 

OPSYSTEMSOENT  PROCS;  FISCAL  ATTRS<~>AUDIT  PROCS  | 
OPSYSTEMSO{fORMAL  METHODS, INTEL, HUMAN  ASSETS}  | 

PiNTENTSOMISSION  STATEMNTS;  RULESOPOLICY  STMTS  | 

ENTERPRISESOLOGOS;  PRODUCTS<-^BRAND  NAMES 

enterpriseso{architectures,opsystems, products}  | 

processes^moes;  products<->cost/qual/perfmnce  I 


INDUSTRIESOSIGNATURES;  AGENCIES<->BEHAVIORS 


P0PULATI0NS^{SUBSPECIES, SPECIES, GENUS,. . ., DOMAIN} 


productsodefects;  processes<->capability  gaps 
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